Javascript Enlightenment

Cody Lindley

Уровень знаний: средний
Тщательный обзор мировоззрения JavaScript через разбор встроенных объектов и нюансов.

Открыть

Eloquent Javascript

Marijn Haverbeke

Уровень знаний: начинающий
Вводная книга по JavaScript и программирование в целом.
Открыть

Building A JavaScript Framework

Alex Young

Уровень знаний: продвинутый
Избранные статьи из цикла«Let’s Make a Framework».
Открыть

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

Но все же я продолжаю настаивать на той точке зрения, что работа это для рабов. Это скрыто в самом названии слова. Работа это то, что делается от нужды, через силу. Под давлением обстоятельств. То, чем человек не стал бы заниматься имей такую возможность. Работа не может быть любимой — это самообман.

В противовес работе есть другое слово — дело. Дело это то, что захватывает, приносит удовольствие. То чем бы человек занимался даже если бы ему пришлось за это платить. То, чем можно гордиться, что является предметом самореализации. Любимое дело раскрывает потенциал человека, высвобождает чудовищную производительность и самоотдачу. Желание сделать лучше и совершенней. А раз так, то резко растет качество и эффективность труда. И, естественно, возрастает доход с дела. За качество готов платить каждый из вас, я в этом не сомневаюсь.

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

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

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

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

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

Если бы мне пришлось писать книгу о том, как создавать немасштабируемые приложения Oracle, первая и единственная ее глава называлась бы «Не используйте связываемые переменные».
Том Кайт, вице-президент Oracle

Недавно на Хабре появилась статья от AlexanderPHP «SQL injection для начинающих. Часть 1». По ее содержимому и комментарием к ней может создаться впечатление, что у многих разработчиков нет понятия, что такое связываемые переменные, зачем ими следует пользоваться и какие преимущества они дают. Попытаюсь в данной статье пролить небольшой свет на данные вопросы.

Я собираюсь сделать Java-веб-приложение (да, это будет Java, по некоторым причинам, которые сейчас озвучивать не хочу). В процессе работы, я оцениваю кучу J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container фреймворков.

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

Давайте представим, что я решил сделать шкафчик для специй.

Автор: Джоэль Спольски. Оригинал.

Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.

Сегодня много кто слышал про ITIL: ИТ процессы, инциденты, тикеты и прочие составляющие ИТ менеджмента.
Слышали? — Круто!
Нет? — ничего страшного, еще обсудим.

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

В то же время по этим самым IT процессами (в том самом виде, в котором они задумывались авторами ITIL) мне посчастливилось проработать аж три с половиной года — поэтому всю «кухню» знаю с практической стороны и знаю, что всё это реально, черт возьми, работает не только на бумаге, но и в жизни.

Сегодня поговорим об одном из самых важных ИТ процессов в плане поддержания стабильности инфраструктуры организации — Управлении Изменениями, он же Change Management.

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

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

"Мама мыла раму":

(предложение
    (именная гр. (сущ мама))
    (глаг. гр. (глаг мыла)
        (именная гр. (сущ раму)))
    (. .)))

Это называется синтаксическим деревом предложения. В графическом виде его можно представить следующим образом (в упрощенном виде):

Небольшой дисклеймер

Эта статья не про продуктовые компании – там своя специфика, я пишу только про сервис. Эта статья не про большие проекты – максимум 6-7 человек, на больших всё по-другому.

Обещаете не писать в комментариях, что в вашей компании все эти трудности преодолели, и вообще нет менеджеров? Тогда добро пожаловать под кат!

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

• Привлечение внимания
• Борьба за власть
• Месть и личные нападки
• Беспомощность

У каждого из этих видов есть свои формальные признаки и стандартные лекарства.

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

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

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

Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.

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

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

Как все мы знаем, пароли следует всегда хэшировать с помощью медленного алгоритма с использованием соли. Чаще всего применяют scrypt, bcrypt или PBKDF2, но этот пост не о том, какой алгоритм использовать. Вместо этого мы поговорим о том, что делать с хэшами дальше.

20- (или 32-) байтовые соль и хэш должны храниться в энергонезависимом, зарезервированном, надёжном хранилище, то есть обычно в реляционной базе данных. Но в каких именно таблицах их хранить? Чаще всего используется таблица со столбцами (user_id, salt, hash) или столбцы salt и hash могут быть в общей таблице Users. В обоих случаях хэш и соль находятся в отношении один-к-одному с пользователями.

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

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

В сегодняшнем посте я хочу обсудить тему — эффективного IT собеседования.
Она родилась из комментария к одному из моих прошлых постов: «Было бы здорово почитать развернутый рассказ про то, как собеседовать людей.» Собственно, сказано — сделано!

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



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

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

Если вам эта тема интересна и есть чем поделится с хабрачитателями — прошу под кат.
+ Бонус в конце статьи.

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

В продолжение предыдущего топика "Как на самом деле работает мозг". На написание данного поста меня побудила, с одной стороны, замечательная книга «Grooming, Gossip, and the Evolution of Language» Робина Данбара (Robin Dunbar), а с другой — очередная порция «полезных» и «умных» советов в GTD и других блогах.

Для затравки — небольшая логическая задачка. Дан набор карточек; на каждой из них на одной стороне написана буква, на другой — цифра.
На столе лежат четыре карточки: «А», «Д», «5» и «6». Вам говорят: если на карточке (из числа лежащих на столе) на одной стороне гласная, то на обороте — чётная цифра. Какие из карточек достаточно перевернуть, чтобы однозначно подтвердить или опровергнуть это утверждение?

Подумайте немного, запишите ответ на бумажке и добро пожаловать под кат.

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009, где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи — это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.