21 из 100. Комьюнити, поднажми!📝
Support us

Неделя за 10 ссылок: почему программисты снова становятся инженерами

Оставить комментарий
Неделя за 10 ссылок: почему программисты снова становятся инженерами

История создания 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.


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

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

 

 

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

Читайте также
Сверхзвуковая авиация и батарейки из бактерий. Техдайджест
Сверхзвуковая авиация и батарейки из бактерий. Техдайджест
Сверхзвуковая авиация и батарейки из бактерий. Техдайджест
Influit изобрела электробензин, Baidu запустила роботакси. Технодайджест
Influit изобрела электробензин, Baidu запустила роботакси. Технодайджест
Influit изобрела электробензин, Baidu запустила роботакси. Технодайджест
Каждую неделю собираем новости технологий, видео и ссылки на полезные статьи.
1 комментарий
Synchron вживила свой первый нейроинтерфейс, Subaru нашла новую Суперземлю. Технодайджест
Synchron вживила свой первый нейроинтерфейс, Subaru нашла новую Суперземлю. Технодайджест
Synchron вживила свой первый нейроинтерфейс, Subaru нашла новую Суперземлю. Технодайджест
Каждую неделю собираем новости технологий, видео и ссылки на полезные статьи.
Возрождение OneWeb и «эра мяса из пробирки». Техдайджест
Возрождение OneWeb и «эра мяса из пробирки». Техдайджест
Возрождение OneWeb и «эра мяса из пробирки». Техдайджест
Каждую неделю собираем новости технологий, видео и ссылки на полезные статьи.

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.