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

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

На Хабре присутствует довольно много бизнесменов, еще больше фрилансеров и работающих по найму.

Большинство из нас (уж я-то точно!) попалось в ловушку жизненной колеи, утверждённой социумом, как стандарт: школа => институт => работа по найму. Кто-то сразу подался во фриланс или бизнес.

Но далеко не всегда выбор сделан осознанно.
В этой статье я попытаюсь объективно рассмотреть плюсы и минусы каждой организационной формы самореализации для того, чтобы такой выбор можно было сделать. Лично я после глубоко переосмысления бросил перспективную карьеру и ушёл в свой стартап.

Приступим к сравнению по набору параметров, которые я считаю наиболее важными, все оценки субъективны — на основании собственного опыта работы по найму + бизнеса, а также опыта работы знакомых по фрилансу.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

Вы занимаетесь веб программированием. У вас есть пользователи, которые оценивают контент на вашем сайте. Вы хотите разместить высоко оцененный контент наверху, а низко оцененный — внизу. Для этого на основе пользовательских оценок вам нужно вычислить некий «рейтинг».

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

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

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

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

Прочтение этой статьи: 15 минут
Осмысление методики: 10 минут
Ощутимые результаты: 30 минут

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

Это шаблон описания сути вашей компании или проекта в одном предложении. Я открыл его для себя во время стажировки в США. Составив его, мы реально становимся сильнее. В последствии мне это помогло выбрать правильный курс, сфокусироваться и расставить приоритеты.

Замечали ли вы, как мало в нынешней культуре уделяется внимания профессии IT-шника? Казалось бы — всё вокруг пропитано интернетом, социальные сети объединили людей, мобильные технологии перевернули мир и т.д. Но где же творцы всего этого великолепия? Где книги о них? Где фильмы, комиксы? Где постеры с выдающимися разработчиками над кроватями подростков? Где фантики жвачек и брендированные игрушки? Где фан-клубы и подражатели? Нету этого всего. Из книг есть разве-что Ник, а из фильмов — Социальная сеть (да и они на самом деле не о программистах, а о магии и бизнесе, соответственно — это людям интереснее). Всё остальное — либо истории про хакеров в духе «мы взломаем Пентагон за 25 секунд», либо посты на гиковских ресурсах вроде Хабра, либо финансовые сводки о том, сколько кто-то там заработал денег на IPO. А всё почему? А потому что в массовом сознании людей работа программиста выглядит неинтересной и скучной. Вот такой, как на картинке справа

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

Мне хотелось бы объяснить другим людям, не связанным с ИТ-технологиями, что видят они совсем не то, что происходит на самом деле. Вот заходите вы в комнату, где сидит человек пять «компьютерщиков». Все что-то там набирают, кнопают кнопки, усиленно пялятся в экраны. Но это только их тела. Самих их здесь нет. А где же они?

Мы, программисты — самые оптимистичные люди, из всех, кого я только встречал. Спросите любого из нас, сколько времени займёт сделать ту или иную вещь — и вы получите супер-оптимистеческий ответ, очень далёкий от реальности. Это не потому, что мы специально стараемся вас дезинформировать и запутать, нет. И не потому, что мы глупы. Просто мы смотрим на всё с оптимизмом.

Вот есть проект, вот наши знания и возможности, вот ваши спецификации, вот Неведомые Загадочные Вещи… Последнее, конечно, самая большая проблема. Нельзя заранее предусмотреть всего и есть большие шансы встретить в тихом болоте таких громадных чертей, что вся Королевская Рать будет их бороть очень долго. Но всегда хочется верить, что их не будет. И вот мы даём оценку времени «1 час», начинаем работать, встречается одна странность, вторая, баг в чужом компоненте — и вот уже на задачу ушел целый день, а она еще не закончена.

Есть, к стати говоря, еще одна профессия, люди которой также дают оценки в условиях неопределенности. И тоже часто ошибаются. Это доктора. Давайте ка я расскажу вам две истории об оценках времени.

Доброго всем дня, вечера, здравствуйте, коллеги.

Сегодня, глядя в календарь, я понял, что в этом месяце отмечаю 8 лет успешной freelance-занятости. Нельзя сказать, что на протяжении этих лет мне приходилось постоянно узнавать для себя что-то новое в организации процесса работы, однако каждое новоприобретенное знание улучшало либо качество моего труда, либо качество моего отдыха.

Я бы хотел рассказать об особенностях freelance-занятости для людей, которые никогда этим не занимались, но хотели бы иметь набор полезных советов, когда захотят попробовать. Приступать к какому-либо делу подготовленным — всегда хорошая идея.

В октябре я уже рассказывала о способах оценки тестирования, все страждующие и сочувствующие могут посмотреть запись здесь. А сегодня мне захотелось затронуть тему метрик проекта в целом, причём метрик не «длягалочных», а метрик «пользуприносящих» и «проектыулучшающих». Именно поэтому, вместо сухих формул и перечня метрик, я расскажу 3 истории из опыта о внедрении и использовании строго определённых метрик в строго определённых условиях — и о результатах, которые с их помощью удалось достичь.

Зачем что-либо измерять?

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

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

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

А если не приходят, значит метрику можно смело выбросить ;)

Доброго всем времени суток!

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

Когда я вижу друзей, которые вкалывают в два раза больше, а зарабатывают в четыре раза меньше, каждый раз начинается разговор:
— А ты бы не хотел поработать программистом? Ты же реально умный. Может ты просто не на своем месте?

В результате я переучиваю своих друзей и знакомых на программистов. Весь процесс занимает от двух до трех месяцев. 25 уроков по 4 часа. Потом все смогли устроиться программистами.
Эта статья не о том, как надо учить, скорее просто описание процесса, который работает.

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

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

Часть 1
Часть 2

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

В первой части я постарался дать понимание относительно того, как выбрать заказчика/исполнителя для проекта. Естественно, в одной статье нет возможности перечислить все, с чем приходится сталкиваться, но основы я постарался описать.

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

Ну, от слов к делу

Каждый, кто имеет дело с IT в той или иной форме, так или иначе сталкивался/слышал о том, что существует такое явление, как фриланс. Как может показаться на первый взгляд, фриланс несет в себе одни плюсы. Ни тебе работника в офисе, для которого надо организовать рабочее место, ни проблем с оформлением его по ТК и последующим увольнением (если нанимать на четко заданный объем работ). Так же стоимость фрилансера, как правило, оказывается от 2 до 20 раз меньше, чем у фирмы, предлагающей те же самые услуги.

Тем не менее, существует огромное количество негативного опыта работы с фрилансом. О его приинах и возможных способах устранения — под катом

Всё начиналось в меру невинно. На первом курсе ты экспериментировал один или два раза, но Nano и Pico были проще, они были ближе к тому, чем ты уже пользовался в средней школе на машинах с Windows и Mac. Но время текло, твой багаж знаний пополнялся тем, что вам давали в вузе, и ты начал что-то замечать: все действительно великие программисты, люди, которым под силу было уместить в 4 строчки, то, для чего тебе требовалось 10 страниц кода, те, у которых богатое функциональностью решение учебного проекта было готово через день, в то время как ты неделями мучался лишь с базой, никто из них не пользовался Nano или Pico.

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

«Как ты это делаешь?» — недоверчиво спросил ты.

Твою жизнь изменил лаконичный ответ, состоящий из одного слога: «Vim.»

Вначале ты был раздражен и куда менее производителен. История браузера являла полный индекс документации Vim, твои Nano и Pico-друзья считали тебя сумасшедшим, Emacs-товарищи умоляли одуматься, ты заплатил деньги за ламинированный экземпляр пямятки Vim. Даже спустя недели тренировок, ты всё ещё по привычке иногда тянулся к мыши, но затем одергивал руку, понимая, что придется искать в сети нужную комбинацию для выполнения рутинной операции, о которой раньше тебе никогда не приходилось задумываться.

Предисловие

Об этом руководстве

Добро пожаловать в первую из четырех частей обучающего руководства по основам Linux, разработанного чтобы подготовить вас к сдаче экзамена Linux Professional Institute 101. В нем вы познакомитесь с bash (стандартной оболочкой командного интерпретатора в Linux), узнаете о большинстве возможностей таких стандартных команд Linux, как ls, cp и mv, разберетесь в инодах, жестких и символьных ссылках, и многом другом. К концу этого руководства у вас сформируется некий фундамент знаний, и вы будете готовы к изучению основ администрирования Linux. К концу всего курса (8 частей), у вас будет достаточно навыков, чтобы стать системным администратором Linux и пройти сертификацию LPIC Level 1 от Linux Professional Institute, если конечно захотите.

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

Я рад приветствовать вас, дорогие читатели.

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

Скажу сразу — я не задаюсь целью мотивировать или призывать к каким-либо правилам эффективной работы, т.к. все слишком индивидуально, чтобы давать подобные советы, но я постараюсь обратить ваше внимание на некоторые, на мой взгляд, интересные детали, лежащие в основе принципов проектирования, которые заметил и осмыслил на собственном опыте. Отмечу также, что статья будет актуальна не только IT-шникам, но и абсолютно всем категориям читателей.