В большинстве встречавшихся мне rails проектов, структура контроллеров не имеет никакой организации и проект растет как придется. В больших проектах это приводит к тому что контроллеры становятся огромными (с десятками actions), а условные фильтры растягиваются на весь экран. Разобраться в таком коде бывает очень не просто.

Поработав с большим количеством rails проектов, у меня был сформирован подход к организации иерархии контроллеров, которая позволила унифицировать их структуру и упростить код.

Мне приходилось участвовать в проектах на c++ с количеством строк более 600 000. Поэтому сложно назвать проект на 5000 строк настоящим. И тем не менее, для хаскеля и мотивации just for fun это немалый объём.

Эта небольшая программа[1] пишется в свободное время, поэтому времени ей сильно не хватает.

Хотелось бы описать некоторые впечатления об использовании хаскеля на практике.

Около 2-х месяцев назад я и TheShock собирали вопросы по JavaScript в теме FAQ по JavaScript: задавайте вопросы. Первая часть, те вопросы, которые достались мне, появилась буквально через несколько дней JavaScript F.A.Q: Часть 1, а вот вторая часть все не выходит и не выходит. TheShock сейчас переезжает в другую страну и поэтому ему не до ответов. Он попросил меня ответить на его часть. Итак вторая часть ответов — те вопросы, которые достались тоже мне.

В рамках моего дипломного проекта мне предложили создать систему формирования проектных команд на основе технологий семантической паутины. Так как я уже переболел голым PHP, SQL, ZF, и имел опыт программирования на Ruby on Rails, ознакомившись с существующими гемами и решениями для работы с RDF, решил писать на нём, т.к. не очень люблю яву (да простят меня ява-разработчики), хотя она и является самым передовым языком в области semantic web, intelligent agents, data mining.

Многие IT специалисты рано или поздно приходят к выводу, что работать на себя эффективнее и выгоднее, чем быть наёмным работником. Набравшись опыта в какой-то области, хочется применить свои знания для улучшения благосостояния, но встаёт вопрос: «с чего начать?» и «где взять деньги для старта?» Как показывает практика, мало кто обращается за помощью к государству, но для начала своего дела все средства хороши и необходимо пользоваться любой возможностью!

Программное обеспечение проникает во все щели человеческого общества. Мы узнаем погоду через интернет, а не через обычный градусник за окном. Мы едем по новому адресу с навигатором, а не ищем квадрат G7 на странице 59. Мы включаем RunKeeper, когда катаемся на велосипеде, чтобы узнать среднюю скорость и похвастаться в твиттере. Мы используем софт каждый день. Наверное, бОльшую часть жизни мы уже проводим в обнимку с любимыми гаджетами и программным обеспечением, а не с любимым человеком.

Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы.

Вторая часть статьи.
Большинство современных вычислительных машин, будь то суперкомпьютер Fujitsu K, обычная персоналка или даже калькулятор, объединяет общий принцип работы, а именно модель вычислений, основанная на потоке управления (Controlflow). Однако, эта модель не является единственно возможной. В некотором роде ее противоположностью является модель вычислений, управляемая потоком данных, или просто Dataflow. О ней я и хочу сейчас рассказать.

Читаете ли вы бизнес-блоги, в которых автор раз за разом описывает свои неудачи?
Нет, потому что вы хотите перенять успешный опыт, а не узнать о полученном опыте от парня, который сам еще не преуспел.

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

Приведу несколько историй, которые помогут понять серьезность этой проблемы.

Следы от пуль

Во время Второй Мировой войны британские бомбардировщики ежедневно отправлялись бомбить немцев. Большинство самолетов не возвращалось домой, а те, что возвращались, были покрыты следами от пуль немецких зенитных орудий и истребителей.

Желая увеличить вероятность возвращения экипажей домой, британские инженеры изучали расположение следов от пуль. Инженеры считали, что в тех местах, где больше всего попаданий, нужно дополнительно бронировать корпус самолета. Разумеется, была найдена закономерность: много следов располагалось на крыльях, хвосте и в районе хвостового пулемета. На кабине пилота и топливных баках следов было мало.

Логично заключить, что нужно добавить брони в тех местах, где больше всего следов. Но это неверно.

Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.

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

Лично мне как руководителю много неудобств приносят люди, которые чем-то недовольны, но молча сидят и ждут. Молча ждут, пока им поднимут зарплату. Молча занимаются неинтересной работой в надежде, что когда-нибудь я это замечу и осчастливлю новым проектом. Молча мёрзнут под кондиционером и уходят на больничный, так и не попросив его выключить.

Люди сидят, молчат и, молча, обижаются. А потом, когда предел ожидания достигнут, они вместо того, чтобы придти ко мне и рассказать о проблеме, также молча идут в соседнюю фирму на собеседование.

Дальше текст немного в «чёрном» стиле Славы Панкратов (case), но это нынче модно. Я надеюсь, вас не смутит обращение на «ты», поскольку оно лучше передаёт эмоциональную составляющую и смысл статьи.

В нашей компании мы не оцениваем работу. Ни в часах, ни в поинтах, ни в зеленых крокодилах. Совсем не оцениваем. Если вы давно хотели отказаться от оценок, но не знали, почему, вот вам пять причин.

1. Вы не будете тратить время на оценки

Оценки занимают время. Даже если вы оцениваете в абстрактных поинтах, играя в покер, все равно тратится прилично времени. А что, если вы хотите улучшить точность оценок? Тогда вы собираете данные, анализируете данные и обсуждаете результаты анализа. Все это тоже занимает прилично времени. Но подумайте, вам на самом деле нужны оценки? Часто это waste. Лучше потратить время на что-то действительно полезное для продукта.

Маркетинг магазина в реале начинается с выбора места. Есть два пути решения задачи: так называемый «жоп-филинг», то есть интуитивное принятие решения и продуманный просчёт.

Общая задача такая:

• Есть интернет-магазин, нужна точка в реале;
• Место должно способствовать наибольшей прибыли точки как отдельного розничного магазина;
• И хорошо работать как пункт самовывоза интернет-магазина.

В 2008 году будущая команда «Мосигры» начала воплощать свою давнюю мечту по изданию качественной отечественной настольной игры. С продажи первой партии «Шакала» началась история розничной сети. Сначала мы открыли интернет-магазин, потом магазин в реале, а затем за два года построили сеть, покрывающую крупнейшие города России, Украины, Беларуси и Казахстана.

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

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

А теперь медленно и по порядку.

Как определить, что сайт сверстан качественно?
Есть много статей о том, как делать хорошо, но совсем нет – о том, как делать не надо, ведь даже валидный и кроссбраузерный сайт может быть сверстан отвратительно.

Из этой статьи вы узнаете:

• О плохих приемах современной верстки;
• О том, как даже не будучи профессионалом, за 5 минут определить плохо ли сверстан сайт или нет.

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.