История создания SaM Solutions и недавний субботник программистов в ПВТ, попытка захвата Kasperksy Lab и схлопывание рынка веб-разработки, а также новые ссылки по Javascript, функциональному программированию, рефакторингу и ООП — в сегодняшнем обзоре ссылок за неделю.

Читать далее

1. История успеха: SaM Solutions

Интервью с Маратом Эбзеевым, директором компании SaM Solutions, об истории создания этой довольно известной минской компании:

Один из наших сотрудников в 1994 году увидел в газете объявление, что Siemens ищет в Беларуси разработчиков программного обеспечения. Само по себе объявление было необычным, но еще необычнее был выбор газеты — кажется, это была «Звезда». Примерно полгода спустя в Минск приехали трое представителей Siemens, которые посетили в том числе и нас. Наш немецкоговорящий (в первую очередь Олег Сукач и Павел Ховренков) коллектив им понравился, особенно проявили мы себя во время совместного ужина в ресторане. Это, по всей видимости, было одно из самых значимых застолий — на многие годы после этого у наших немецких гостей остались неизгладимые впечатления.

Кроме того, на прошлой неделе программист Александр Зихманчук решил своими силами привести водоём рядом со зданием ПВТ в порядок:

«По соседству работают компании с многомиллионными оборотами, а тут — неблагоустроенное болото»

Уже проведено мероприятие субботника: программисты и блогеры вышли на субботник в ПВТ.

Последние плоды кипучей деятельности:

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

Кто хочет поучаствовать в очистке загаженной вокруг ПВТ территории, вам сюда.

И вдогонку: пока одни по субботникам шастают, другие же принципиально новые алгоритмы создают: 17-летний студент из Беларуси создал искусственный интеллект, который сможет мыслить и чувствовать как человек.

2. Почему программисты снова становятся инженерами

Хороший материал от Look At Me: Вице-президент Parallels рассуждает об окончании «эры айтишников»:

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

И ещё одна цитата про «страшные вещи»:

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

3. Рынок разработки сайтов «умирает»

Злободневная статья о падающем рынке веб-разработки:

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

Будучи заодно ещё и одним из учредителей Ассоциации Интерактивных Агентств (АИА), я более или менее представляю себе, как обстоят дела во всех основных конторах по веб-разработке в стране. Проще говоря, я в теме. И вот, что я хочу вам сказать. Похоже, бизнес веб-разработки, веб-студий или «диджитал-агентств» умирает.

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

4. Вирус внутри «Касперского»

История неудавшегося «переворота» внутри Kaspersky Lab — кому лень читать, суть в том, что корпоративный «майдан» таки не прошёл.

Эта движуха живо напомнила мне другую относительно недавнюю историю в изложении Максима Спиридонова из «Нетология-групп» — это триллер для любого владельца стартап-бизнеса (доп. ссылка 1, ссылка 2).

5. Рефакторинг — громадьё ссылок

Свежая серия материалов «Киски: Рефакторинг»: часть 1, часть 2. Часть 3.

В дополнение:

• Рефакторинг: выделяй метод, когда это имеет смысл.
• Не следует давать классам имена, оканчивающиеся на «er».
• Синглтон паттерн на Go.

6. Про модель, логику, ООП, разработку и остальное

Часто ли вы задумываетесь — почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение — как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так? Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?

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

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

В нагрузку выдаю бережно завернутую в https ссылку на другой свежачок: Принцип разделения ответственности и ORM. Там Мицголь в комментариях оппонирует к сказанному в статье:

Чёткого отделения логики от базы не получится в том числе и потому, что примеров проникновения логики в базу (с целью ускорения работы логики) обыкновенно бывает больше, чем три приведённых выше примера. Как только число строк в таблице начинает измеряться тысячами и десятками тысяч, так сразу захочется прибавить к этим примерам ещё одну логику внутри базы, а именно индексы. А сможет ли ORM, вообще ничего не зная о той логике, которой подчинён поиск по базе, создать именно те индексы, которые ускорят такой поиск (и одновременно не насоздавать лишних индексов, которые не принесут пользы, а только замедлят пополнение и обновление базы)? Никоим образом не сможет. Это самообман.

... А с Мицголем лучше не спорить.

7. ФП в вебе

Буквально недавно (в прошлом выпуске) ссылался на использование Lisp в продакшене и разработку web-приложений на языке Common Lisp (часть 1, часть 2, часть 3), тогда как вдогонку вышел свежий материал на аналогичную тему: Веб-приложения на Clojure — часть 1, часть 2.

8. Тунеядцы на стуле или герои-стахановцы?

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

И лишь одной малюсенькой детали в этой статье не хватало. Правды.

Почему программировать так тяжело? против Почему программировать легко.

Программяку на гиляку? Комментарии оттуда в качестве спичек для распалки хвороста холивара:

Программировать легко и весело пока твоя задача не выходит на коммерческий уровень. А ещё легче жить, если ты никогда не увидишь (не будешь отвечать на вопросы) пользователей своей же системы. Типа программируешь — и всё отлично! Наделал ошибок, программа неудобна — ну и ладно, заказчик же платит. Это удобная практика для «заокеанских заказов», где часто есть свой отдел саппорта, а также армия тестировщиков. Но возьмите вариант — «сам себе бизнесмен программист» — и вам придется и ТЗ составить, и общаться, и в ситуации «всё пропало, помогите!» спасать клиента. Так что не все так весело.

Закончить ему хочу жизненной цитатой с «Баша»:

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

9. Уголок джаваскриптера

Свежий материал Ускоряем angular.js или как не выстрелить себе в ногу дополняем Почему вам НЕ стоит использовать AngularJs.

В комментариях к обоим топикам страшный флейм — много защитников и противников AngularJs на земле русской. Я бы выбрал такой вот резюмирующий комментарий из всего многообразия:

После знакомства с Ангуляром мне в голову пришла следующая метафора.

Предположим, у нас есть некоторое приложение. Мы, как архитектор этого приложения, знаем как в нём организованы потоки данных. В приложении мы задекларировали эти потоки данных и то как их следует обрабатывать в виде некоторого кода. То есть у нас описаны некоторые конкретные блоки, которые связаны конкретными линиями-направлениями данных.
В противовес этому, Ангуляр представляет собой что-то вроде «множества универсум», где всё связано со всем. В первый момент это вызывает wow-эффект. В самом деле, путём нескольких деклараций и пары строк кода мы организовали полноценный ввод пользователя, обработку и автоматическое обновление представления (!). Но в дальнейшем становится ясно, что такая полносвязная схема имеет свои побочные негативные эффекты: низкая производительность и сложность восприятия.

Я был очень рад услышать, что идёт разработка Angular 2, который (как и обязано мажорному релизу) будет обладать существенными изменениями, и в частности упрощениями, выпиливанием целой кипы фич. Также, существует разработка angular-light, которая ознаменована той же цели: упростить и оздоровить Ангуляр.

После использования Ангуляра я пришёл к выводу, что лучше строить приложение, основываясь на явных потоках данных. Для этого лучше всего подходит идея FRP. Что замечательно, FRP прекрасно компонуется с существующими библиотеками (я считаю, компонуемость — это очень хороший признак действительно здоровой концепции), например, можно использовать jQuery для получения источников данных (пользовательские события, которые инициируют flow/поток), так и для отображения ($.text, $.html в конце цепочек), также FRP прекрасно дружит со всеми существующими шаблонизаторами. В общем, явное лучше неявного, FRP и компонуемость это будущее.

Также прикладываю новый перевод: Создание красивых диаграмм с помощью Chart.js

10. Тестировщики, наши братья меньшие

Управление тестированием через управление требованиями — образец применения лучших практик:

Технократическая эпическая сага с авторскими иллюстрациями. Анализ типовых проблем с тестированием в крупных проектах. Ответ на вопрос «как же так получилось?», поиск Главного Злодея. Последовательное изложение идеальной истории тестирования ПО с самого начала — от возникновения требований до сопровождения — в формате ролевого взаимодействия. Утопическая демонстрация процесса, ролевой модели и основных этапов процесса производства с предъявлением артефактов в системе ALM и счастливое спасение проекта.

Статистический анализ процессов разработки и тестирования:

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

Иллюстрации: twitter.com, vk.com, movepics.ru

 

 

*Мнение колумнистов может не совпадать с позицией редакции.
**В цитировании сохранены авторская орфография и пунктуация.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.