Прочитав очередные вредные советы про стандарты оформления кода (раз, два, тысячи их), я не смог удержаться, чтобы не поделиться своими измышлениями на эту тему. Долгие годы я вынашивал в своём подсознании чувство «что-то тут не так». И вот, пришло время определиться с тем, что не так, и почему. Рискуя быть закиданным тухлыми бананами, я всё же пишу эту статью тут, а не в своём личном блоге, потому, что это очень важная тема и хочется, чтобы как можно большее число разработчиков поняли её суть и, возможно, пересмотрели свои взгляды на жизнь… кода.

После прочтения Google's AngularJS Guidelines у меня создалось впечатление о его незавершённости, а ещё в нём часто намекали на профит от использования библиотеки Closure. Ещё они заявили, «Мы не думаем, что эти рекомендации одинаково хорошо применимы для всех проектов, использующих AngularJS. Мы будем рады видеть инициативу от сообщества за более общий стайлгайд, применимый как для небольших так и крупных проектов».

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

Видео результата:

Преамбула

Всё время хотелось удобно смотреть ТВ (да, я смотрю ТВ) сразу в xbmc, в красивом интерфейсе с расписанием и пр. плюшками. IPTV мой провайдер не предоставляет, «тарелку» ставить как-то стрёмно, только ремонт сделали, тут опять кабель непонятно как в квартиру заводить. Качество видеопотока с внешнего usb тв тюнера для старого нетбука, выступающего в роли медиацентра, оставляет желать лучшего, да и ловит полтора канала. В общем, со всех сторон облом, долго думал я, пока не узнал о торрент-тв.

Собственно, в статье о том, как его смотреть в нативном интерфейсе xbmc для ТВ.

Самая частая из проблем, с которыми я встречаюсь в проектах, — что менять в первую очередь, на чём фокусироваться. «Как» все знают или считают что знают. У меня припасено несколько хаков, которые позволяют за полдня провести первичный анализ, выявляющий точки фокуса.



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

Здравствуйте, меня зовут Дмитрий Карловский и я… клиент-сайд разработчик. За плечами у меня 8 лет поддержки самых различных сайтов и веб-приложений: от никому не известных интернет-магазинов, до таких гигантов как Яндекс. И всё это время я не только фигачу в продакшн, но и точу топор, чтобы быть на самом острие технологий. А теперь, когда вы знаете, что я не просто хрен с горы, позвольте рассказать вам про один архитектурный приём, которым я пользуюсь последний год.

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

Осторожно: чтение может вызвать вывих мозга, приступ холивара, а также бессонные ночи рефакторинга.

Доброго времени суток! Не за горами релиз PostgreSQL 9.4 и нелишним будет пройтись по некоторым новшествам, привнесённым в этой версии. В статье будут рассмотрены (по большей части, касаемые клиентской модели):

• изменения в автообновляемых представлениях
• изменение в материализированных представлениях
• команда ALTER SYSTEM для установки конфигурационных параметров
• опция WITH ORDINALITY для функций, возращающих набор строк
• новые функции для агрегированных данных
• улучшения для индексов GIN и GiST
• улучшенный вывод команды EXPLAIN
• разогрев кэша
• триггеры для внешних таблиц
• изменения для json и новый тип данных jsonb

Введение

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

В XX веке доминировала методология управления производством получившая название «Фордизм», по имени своего основоположника Генри Форда. Фордизм — модель массового производства стандартизированных товаров на сборочных конвейерах с использованием низкоквалифицированных работников, занятых простыми операциями и объединенных на крупных фабриках. Такое производство обладает «эффектом масштаба» и отличается низкой себестоимостью единицы продукции, доступной массовому потребителю. Один из основных постулатов фордизма: «Производить большие партии изделий выгоднее, чем мелкие», прочно укоренился в головах управленцев XX века.

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

Рождение новых методологий

Со второй половины XX века (после второй мировой войны) предпринималось множество попыток модифицировать фордистскую модель. В частности на заводах «Тойота» в 50х годах стали ставить эксперименты, адаптируя американские концепции массового производства к реалиям послевоенной промышленности Японии. Тогда была переделана система крепления прессового инструмента, чтобы сделать его замену более быстрой. Потом были и другие новаторские решения и открытия, со временем сложившиеся в новую методологию — Lean Manufacturing (LM) – Бережливое производство.

В 80х и 90х появился целый зоопарк методологий и парадигм по управлению производством, среди которых подробнее остановлюсь на двух: Quick Response Manufacturing (QRM) – Быстрореагирующее производство и Agile Manufacturing (AM) – Активное производство. Современные, более гибкие по сравнению с фордизмом методологии, часто объединяют термином «постфордизм».

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

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

Ниже приведена таблица основных отличий фордисткой и постфордисткой концепций промышленного производства [1].

Признак	Фордизм	Постфордизм
Базисная ориентация	Продукт	Клиент
Снижение стоимости единицы продукции	За счет объёмов	За счет быстрой переналадки оборудования
Работник	Рабочая сила (Узкие, малоквалифицированные рабочие)	Носитель компетенций (вектор развития, многофункциональные специалисты)
Организационная форма	Отдельные рабочие места	Командная работа
Отношение к браку	Допустимый уровень	Абсолютное качество
Инновации осуществляются	Специалистами	Всем персоналом

Сейчас подробнее о каждой из рассматриваемых новых методологий

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

Вступление

В 2003 году, хакеру, известному как «HD Moore», пришла идея разработать инструмент для быстрого написания эксплоитов. Так был рожден хорошо известный во всех кругах проект Metasploit. Первая версия фреймфорка была написана на языке Perl, содержавшая псевдографический интерфейс на базе библиотеки curses.

К 2007 году разработчики консолидировались, основав компанию Metasploit LLC; в это же время проект полностью переписали на Ruby и, частично на Си, Python и Ассемблер.

В октябре 2009 года, проект Metasploit был приобретен компанией Rapid7 с условием, что HD Moore останется техническим директором фреймворка, на что согласилась компания Rapid7.

“Да потому что я постоянно этим занимаюсь” — Иван Селиховкин (selikhovkin) в ответ на вопрос, почему мы будем записывать видео именно на эту тему.

После публикации бесплатного курса “Практический PMBoK за 2.5 часа” мы получили массу вопросов про конкретику от тех, кто курс посмотрел, и немало вопросов-сомнений от тех, кто курс не смотрел и вообще сомневается, что курс на 2.5 часа может содержать что-то полезное.

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

Поэтому периодически, когда выдается свободная минутка, занимаемся углублением: развиваем конкретные темы, говорим про инструменты и стараемся ответить на возникшие вопросы. В прошлом видео при помощи Ивана Селиховкина (selihovkin) разбирались с заказчиком. В сегодняшнем видео решили углубиться в алгоритм входа в уже существующий проект:



7 последовательных шагов, которые должен пройти менеджер от своего “медового месяца” к выводам о том, что делать с проектом дальше.

Современный менеджмент включает в себя целый ряд дисциплин, которые объединяют в себе самые различные функции, от менеджмента рисков до управления ресурсами и маркетинга. Сегодня же мы взглянем на менеджмент проекта в рамках IT-компании в общем, опишем главные функции менеджера (каждая из которых включает тысячи подфункций и еще больше всевозможных задач) и опровергнем несколько устойчивых и вредных мифов. Эта статья для начинающих PMов, а также для тех, кто вырос в менеджера из программиста.

Контрольный вопрос: чем менеджер отличается от подчиненного? На самом деле, основное отличие – это ответственность за результат. Менеджер отвечает за результат всей команды. На этом фоне ни решение задач, ни зарплата не является основной отличительной чертой между подчиненным и менеджером.

После прошедшего PM-Weekend удалось поймать selikhovkin и попросить записать несколько видео по самым популярным вопросам про управление проектами. Сегодня — первое видео:

10 ответов на вопросы про работу с заказчиком

В рамках видео Иван тезисно раскрыл следующие вопросы:

1. Как заинтересовать бизнес в повышении зрелости системы управления?
2. Методы по формированию ожиданий у заказчика по проекту и их использование
3. Как понять, что хочет заказчик?
4. Как удерживать заказчика от раздувания требований?
5. Как научить заказчика доверять разработчику?
6. Какие методики/методологии ведения проектов и общения с заказчиком существуют?
7. Саботаж сотрудников заказчика (как бороться)?
8. Как сообщить заказчику, что проект идет не по плану, какие фразы использовать, как сгладить впечатление?
9. Особенности работы с гос.заказчиками
10. Что делать менеджеру на проекте, который заказчик пускает на самотек?

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

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

Хоть я и пообещал, что после прочтения этой статьи, можно будет играть в Metro 2033 на калькуляторе (шутка, такого не будет), все же она начнется с рекомендации купить кое-что из железа, если у вас этого еще нет.

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

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

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

Хочу рассказать о некоммерческом проекте Кодабра. Здесь мы учим детей программировать и создавать игры.

Предыстория

Как-то пришло осознание того, что максимум удовольствия в этой жизни фаундерам приносят три процесса — программирование, обучение других и общение с детьми. Мысли стали активно бурлить по поводу школы для детей, а активные действия начались с января 2014. Нас вдохновили такие проекты как codeclub.org.uk, code.org, cs-first.com. И мы решили использовать их опыт и организовывать бесплатные уроки на базе существующих школ, детских домов и иных детских учреждений.

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

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

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

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

Любой проект посложнее «Hello World» состоит из некоторого количества файлов, по которым разносят код. Это дает возможность структурировать проект, вынести независимые части, которые можно будет использовать в других проектах и вообще сделать код нагляднее.

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

    var authModule = require('./auth');

Данный код подключает модуль авторизации и делает его доступным через переменную authModule.

В зависимости от того, какой параметр передан в функцию require, будет отличатся алгоритм подключения модуля. Так что давайте посмотрим на принципы подключения модулей в Node.js. Отмечу, что вся эта информация доступна в документации.

Вместе с Node.js поставляется несколько встроенных модулей, для подключения которых нужно просто указать название модуля.

    var http = require('http');
    var cluster = reqiure('cluster');

Нужно отметить, что встроенные модули имеют приоритет над всеми остальными, если в функцию require передано их название. Так к примеру, require('http') всегда вернет встроенный модуль, даже если будет сторонний модуль с таким названием или файл с таким именем. Список всех встроенных модулей и документацию по ним можно найти на сайте. Исходники этих модулей можно посмотреть в репозитории проекта.

AngularJS молод и горяч, когда дело доходит до современной веб разработки. Его уникальный подход к компиляции HTML и двусторонней привязки данных делает его эффективным инструментом для создания клиентских веб приложений. Когда я узнал что Quick Left (студия в которой работает автор. прим. пер.) будет использовать его для создания приложения для одного из наших клиентов, я был взволнован и постарался узнать о angular столько сколько мог. Я обошел весь интернет, каждый урок и руководство, которые смог найти в Google. Они были реально полезны в понимании работы директив, шаблонов, компиляции и цикла обработки событий (digest), но когда дело дошло до тестирования, я обнаружил что эта тема была просто упущена.

Я обучался подходу TDD (Разработка через тестирование) и я чувствую себя не в своей тарелке без подхода «Красный-Зеленый-Рефакторинг». Так как мы все еще разбирались что к чему в тестировании в Angular, команде иногда приходилось полагаться на подход «тестирование-после». Это начало нервировать меня, поэтому я решил сосредоточится на тестировании. Я потратил на это недели, и в скором времени покрытие тестами поднялось с 40% до 86% (Кстати, если вы еще этого не делали, можете попробовать Istabul для проверки покрытия кода в вашем JS приложении).