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