alanvanduke

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

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

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

Сегодня с товарищами идем в пивнушку. Если бы не вторник — было бы гораздо интересней! P.S.: Не забудьте сегодня сделать коммит в какой ни будь опэнсаурс проект: // Happy Programmers Day!

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

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

В базе есть внутреннее разграничение хранимой информации. Если вы явно не указываете индексировать поле, например, content, то база индексировать его не будет. Помимо этого, насколько мне известно — типы, например TEXT, в БД хранятся как то отдельно от общих данных. Тем более вам стоит использовать «урезанные» запросы, где производится выборка только определенных данных, а не всех подряд. Правильнее: SELECT p.title, p.date FROM pages AS p Чем SELECT p.* FROM pages AS p И как подсказал ShumNo — вам никто не запрещает использовать кэш.

Да ну? А мне показалось область применения несколько шире.... 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, но кажется идет блокировка отдельных таблиц, а не всей базы, когда в SQLite блокируется полностью вся база.

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

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

Добрый день. Сегодня на Хабре выложили статью по поводу целесообразности использования новых тэгов HTML5. Избегаем распространенных HTML5 ошибок Хотелось бы, чтобы это не было одним сообщением в теме, а предлагаю здесь делиться рецептами «правильного» использования HTML5 разметки.

Даже есть http://code.google.com/p/jquery-websocket/ Разжеванное http://habrahabr.ru/blogs/webdev/94921/ Собственно достаточно информации по этому поводу http://habrahabr.ru/tag/websocket/

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

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

Команда уже есть, даже не одна, а уже четыре. Три команды java- разработчиков и одна команда тестеров. Нужны именно верстальщики и дизайнеры. Сейчас идет четвертая итерация, т.е что-то уже сделано. Это все-таки не стартап. Какой профит- каждый решает для себя сам. В общем случае, опыт и личный интерес. Вот здесь видение того, что должно получиться: Vision Извините, не в тему, а в какой программке рисовались вот такие вот симпатичные картинки в "Видении"? Уже не раз на такие "скриншоты" натыкаюсь... Но не у кого было спросить.

window.parent

Блин, код теста на сайте IE-testdrive. if(browserInfo.isInternetExplorer() && browserInfo.version() >= 9) { testPassed = true; }

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

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