alanvanduke

Противоречивая версия.

1 гигобатл = 1024 мл

Мы выпили 1 ГБ водки. Разговаривали громко про хабр и всякую сетевую всячину.

а как программисты отмечают день программиста?

Сегодня с товарищами идем в пивнушку. Если бы не вторник — было бы гораздо интересней!

P.S.: Не забудьте сегодня сделать коммит в какой ни будь опэнсаурс проект:

// Happy Programmers Day!

Присоединяюсь к поздравлениям. Желаю вам качественного кода, послушных багов, менеджеров без параноидально-дерессивных наклонностей, клиентов белых и пушистых, много-много пива хорошего!

Пусть в жизни вам будет код и не только!

Подкину перл:

xxx: слух, короче мне надо созданную базу кинуть в папку с сss

xxx: я праивльно поняла?

Девушка просто ошиблась и написала CSS вместо CMS, но зачем (и как?) кидать созданную БД в папку с CMS тоже неясно…

Да понятно, с базами работаю. При размышлениях возникает желание идентификатор статьи, дату публикации, автора и т.п. держать в базе, а саму статью в файле ибо индексация содержимого файла не требуется - какой смысл держать текст в базе. Может я где то потеряю в удобстве или производительности???

Я уже вижу цикл выбирающий из десяти файлов первые десять строк (список новостей к примеру) и возникает вопрос - быстрее ли будет выборка таких данных из базы.

В базе есть внутреннее разграничение хранимой информации. Если вы явно не указываете индексировать поле, например, content, то база индексировать его не будет. Помимо этого, насколько мне известно — типы, например TEXT, в БД хранятся как то отдельно от общих данных. Тем более вам стоит использовать «урезанные» запросы, где производится выборка только определенных данных, а не всех подряд.

Правильнее:

SELECT p.title, p.date FROM pages AS p

Чем

SELECT p.* FROM pages AS p

И как подсказал ShumNo — вам никто не запрещает использовать кэш.

Шаблонизатор для JavaScript необходим в очень крайних случаях.

Конечно если у вас NodeJS приложение, то тогда другой разговор.

Да ну? А мне показалось область применения несколько шире.... http://vremenno.net/examples/mustache-template-engine/

В последнее вресмя как то запарило делать что-то наподобие

  var DescSEO  = '<p><img src="img/option_seo.png" /><strong>Internal SEO</strong> <b>Анализ внутренних SEO параметров сайта.</b></p> <ol><li>robots.txt</li> <li><meta /></li> <li>контент</li> <li>ошибки</li> </ol>';
  var DescYa   = '<p><img src="img/option_rank.png" /><strong>Yandex SEO</strong> <b>Анализ авторитетности сайта Яндекс.</b></p> <ol><li>страниц в индексе</li> <li>обратные ссылки</li> <li>соц.ссылки</li> <li>каталог</li> </ol>';
  var DescGgl  = '<p><img src="img/option_rank.png" /><strong>Google SEO</strong> <b>Анализ индексных параметров сайта Google.</b></p> <ol><li>страниц в индексе</li> <li>обратные ссылки</li> <li>соц.ссылки</li> <li>PageRank</li> </ol>';
  var tipStat  = '<span class="act"><i>клик:</i> включить или выключить</span>';
  var DecChg   = '<span class="act change">выбранная опция включена</span>';
  var DecUnChg = '<span class="act">выбранная опция отключена</span>';
  var Progress = '<div id="loader"><p><img src="img/loading.gif" /> обработка началась, ожидайте ...</p></div>';

И все эти штуки можно было бы зашаблонить, а текст тянуть JSON. Довольно частый случай, когда приходится DOM достраивать.

А чем обычный str.replace() не подходит?

var str = '<a href=":link">:text</a>';

var out1 = str.replace(':link', 'http://test1.ru/').replace(':text', 'Test 1');
var out2 = str.replace(':link', 'http://test2.ru/').replace(':text', 'Test 2');

По моему куда уместней.

Мне сначала помогла неплохая книжка «Дизайн для не дизайнеров», автор Робин Вильямс (девушка).

Просматривать картины конечно полезно, но я бы еще посоветовал перечитать полностью рецензии из бизнес-линча, а так же покрутиться на форумах в ветках, где обсуждают работы новичков и почитать что пишут о других. Так вы поймете «как делать нельзя».

А так же стоит показывать свои работы как можно большему числу людей, слушать критику и научиться «не фыркать» на неприятные слова в адрес ваших работ.

Если вы рисуете сайты, то вам стоит рассматривать красивые и качественные сайты, а не картины.

P.S.: Не сочтите фанатом Лебедева — просто он дает неплохой старт в развитии.

Насчет Ководства — умные мысли есть, но есть книжки и по лучше. Начните с типографики хотя бы.

Есть ли смысл затеваться с хранением блогов/ностей/страниц в файлах, какие недостатки и преимущества. Есть ли смысл разгружать базу перемещая эти данные в файлы?

Если у ваших данных предполагается наличие связей, то идея хранить информацию в файлах — плохая. БД предлагает достаточно приятный SQL язык запросов, чтобы выбирать связанные цепочки данных, поэтому для обычной статики — файлы неплохо, для блога с категориями — не очень.

Шаблонизатор для JavaScript необходим в очень крайних случаях.

Конечно если у вас NodeJS приложение, то тогда другой разговор.

Да, «дизайн» формы не тот. Это потому что очень мало дизайнерского опыта. В общем дизайнером может стать каждый: просто нужен не один год, что бы понять: а что же пользователям действительно нравиться.

Новоиспеченный «дизайнер» обычно начинает впадать в крайности. А крайности — это либо куча куча всего, обводки, шрифтов побольше, ну собственно то, что представил нам ТС, и конечно же не продуманное юзабилити. Это сродни когда маленькая девочка растет, и когда начинает краситься, то намазывает на себя все, что нашла у мамы в косметичке. Вот как то так.

Как к делу подходит «про»-дизайнер. Если честно ему уже плевать. Он выстраивает определенную сетку. В загашнике у него достаточно много определенных правил, которые он либо подсмотрел, либо сам дошел до понимания сути. Обычно «про» стремятся к минимализму, и советуют это начинающим, тогда начинающие начинают уж очень сильно стремиться к этому, и делают одну кнопку на странице с надписью «Кнопка».

В общем суть: крайности опасны.

Конечно начинающим такие вот топики дают многое, поэтому они должны быть, хоть это и фэйл. Каждый «про» когда то точно так же набивал кучу шишек.

Советы по самому сабжу:

• Кнопки. Пишите на кнопках осмысленное название действия, которое должно произойти. Просто «Принять» не подходит, потому что не понятно: что произойдет после этого «Принятия». Правильней писать: «Перейти к шагу 2» или название «Перейти к …» и читайте следующий пункт.
  
• О шагах. Лучше называть «шаги» не шагами, а дать название каждому этапу. Например для магазинов: «1. Информация о заказе» ? «2. Данные для доставки» ? «3. Подтверждение заказа».
  
• Отвратительный шрифт. Просто отвратительный и все. Советую научиться для начала применять обычные Arial, Helvetica, Times new Roman, а уже затем начинать пробовать эксперементировать с другими шрифтами. Косое начертание используется для придания акцента отдельным словам или цитатам, или если это выглядит гармонично и уместно (литературный сайт например), но использовать его где не попадя — запрещено.
  
• Подсказки. Вы ввели в форме некие «маски» для ввода информации, но не объяснили пользователю формат вводимых данных. Пользователи такие формы просто не будут заполнять.
  

Каждому «программисту» будет полезно подучиться немножко дизайну, как и каждому дизайнеру стоит открывать книжки по программированию. Поэтому это нормально.

Учитесь, развивайтесь, успехов!

Можно подумать, mysql не блокирует доступ к файлу. Это что ж там за файловая система?

Естественно MySQL блокирует файл, который на диске. Если честно, то не знаю точно как построена блокировка файлов в MySQL, но кажется идет блокировка отдельных таблиц, а не всей базы, когда в SQLite блокируется полностью вся база.

В общем то да, когда читал текст, сам немножко был недоволен переводом. Но интересней примеры кода. В общем было бы не плохо, если бы из под пера Влада вышла статься выдержек из HTML5 рекомендации. Хотя, насколько мне известно, рекомендация пишется постоянно, поэтому хотелось бы услышать просто базовые правила, на которые можно будет опираться, а то тегов придумали много, а как с ними работать не ясно…

Неправильно наверное сравнивать работу с файлами и базы данных. И то и другое, как уже было подмечено выше — работа с файлами. Просто если у вас довольно много логических связей в хранимой информации — нужна удобная надстройка — БД, чтобы легче оперировать данными.

Так что предмета спора не вижу.

Для «систем управления» (которые чуть более сложней простой отдачи статического контента) — лучше БД, потому что это хоть как то гарантирует целостность хранимой информации. Хотя в этой фразе я сам не сильно уверен, потому что транзакции есть только в InnoDB.

Насчет SQLite vs MySQL — если у вас совместный доступ к базе (над базой трудятся несколько человек), то конечно же MySQL, потому что SQLite полностью блокирует доступ к файлу базы, если в него уже «кто то пишет». Ну и на больших объемах и сложных запросах MySQL покажет себя лучше (хотя, для этого нужно проводить специальные углубленные тесты).

Вывод: вопрос «Использовать или не использовать технологию?» нужно задавать себе каждый раз исходя из поставленной задачи. Хороший программист должен владеть и файлами, и SQLite, и MySQL (различать +/- MyISAM и InnoDB, а хорошо бы знать еще пару тройку других БД), и использовать каждую из этих технологий в зависимости от тех условий, в которых работает его приложение.

Добрый день.

Сегодня на Хабре выложили статью по поводу целесообразности использования новых тэгов HTML5.

Избегаем распространенных HTML5 ошибок

Хотелось бы, чтобы это не было одним сообщением в теме, а предлагаю здесь делиться рецептами «правильного» использования HTML5 разметки.

Ну всё от задачи зависит. Где-то и без флэша можно обойтись, используя какой-нибудь ajax push engine, например. Но надо понимать, что большое количество обращений к веб-серверу дадут нехилую нагрузку, да и пулы какие-нибудь придётся организовывать поди... Вроде как можно реализвать сокеты на JS в новых браузерах, но не знаю точно — давно «одна бабка сказала», уверенности нет.

Даже есть http://code.google.com/p/jquery-websocket/

Разжеванное http://habrahabr.ru/blogs/webdev/94921/

Собственно достаточно информации по этому поводу http://habrahabr.ru/tag/websocket/

В книге Якоба Нильсена говорилось о жизненном цикле браузера... Так прозвучала фраза, что IE6 нужно будет еще поддерживать до 2012 года. Потом можно будет окончательно забить.

Мое мнение: Лебедев устарел. Единственное, что от него осталось нормальное - это Ководство. Оно дает начальные знания о дизайне.

Еще есть множество работ, которые, считаю, нужно ставить в пример.

Насчет перегнали... Здесь сложно что то сказать однозначно. Студия всегда была "в струе", не знаю причин по которым они должны стать "не модными" и их должны перегнать (по крайней мере на постсоветском рынке и в плане дорогого дизайна).

Чтобы привлечь к стартапу людей, сначала что-то сделайте. Покажите потенциал. Пусть это будет корявый продукт, но он должен быть. Иначе это утопия так людей в команду набирать.

Команда уже есть, даже не одна, а уже четыре. Три команды java- разработчиков и одна команда тестеров. Нужны именно верстальщики и дизайнеры. Сейчас идет четвертая итерация, т.е что-то уже сделано. Это все-таки не стартап.

Какой профит- каждый решает для себя сам. В общем случае, опыт и личный интерес.

Вот здесь видение того, что должно получиться:

Vision

Извините, не в тему, а в какой программке рисовались вот такие вот симпатичные картинки в "Видении"? Уже не раз на такие "скриншоты" натыкаюсь... Но не у кого было спросить.

window.opener?

window.parent

Блин, код теста на сайте IE-testdrive.

                    if(browserInfo.isInternetExplorer() &&
                       browserInfo.version() >= 9) {

                        testPassed = true;

                    }

Сначала конечно была болезнь: сделать что то по подобию другого сайта. Но всегда было врожденное пренебрежение к воровству. То есть саму идею или смысл украсть можно, но дойти до реализации нужно обязательно самому. Вот как то так методом проб и ошибок начал верстать. Сначала выучился табличной верстке по документу, где были описаны основные тэги. То есть В общем то никаких дополнительных средств не было. Просто исходные коды других страниц и дока с описанием тэгов. Хотя давненько это было, уже и не помню как точно начинал все.

Главное что у меня было: ярко выраженная любовь к верстке до фанатизма. То есть это не было чем то типа: "О, а на этом можно поднимать деньги". Это было чувство, с которым, например рубятся в КС, повышая скилл. Вот как то так.

alanvanduke, так ты программером тоже работаешь?

Ну да, есть такое.

Сочинение на тему: "Почему я хочу стать верстальщиком"

Автор: Great Rash

Версткой заинтересовался случайно (в 2000 году примерно) когда коллега по работе сделал шутки ради один забавный сайт. Кстати, он еще жив оказался, и даже дизайн сменился (делалось в замечательной программе Microsoft Word)

Я подумал, что тоже так хочу и начал клепать свои говносайты. Лет 5 это оставалось хобби, а потом, совершенно случайно, переросло в профессию...

А вообще задолбала меня верстка... Не хочу я быть столбовою дворянкой верстальщиком, хочу быть владычицей морскою программером. Поэтому сейчас читаю книги всякие разные. Я слишком ленив для фриланса и наглости у меня нет, чтобы бабло версткой грести, да и программирование меня всегда как-то больше привлекало.

Где то было написано, что верстальщики свое ремесло за ремесло не считают и лезут программировать, в дизайн и т.п., где становятся посредственными в исполнении работы, и не все у них получается. Вот собственно частенько именно поэтому сложно найти нормального верстальщика, который бы думал и знал, что делает ответственное и важное дело!