Телеграм канал Темная сторона IT
О чём обычно молчат в IT коллективах.
Поделиться с друзьями:
статистика поднять канал
О чём пишут в канале @darkside_it
На днях на Хабре вышел перевод статьи “Докер мертв”. Заголовок настолько желтый, что глаза режет. Но все-таки стоит сказать пару слов об “умирании” технологий.
В мире нет такой технологии, которая бы одномоментно умерла и ее сразу же перестали изучать, использовать и поддерживать. Это долгий процесс.
Никто не бросается переписывать свой проект только потому, что кому-то показалось, что технология умирает или её разработчики (или мейнтейрнеры) забросили развитие. Более того, даже если поддержка прекратилась — текущий продакшн никто не отключит и не перепишет, т. к. это требует денег и времени. А зачем тратиться на то, что прекрасно работает, решает свою задачу и улучшать это все равно не планируют?
Популярные (и не очень) технологии обрастают различными сообществами, которые организуют форумы, чаты, рассылки и так далее. Сообщества обеспечивают неофициальную поддержку. Поэтому, даже если официальный разработчик “ушел на пенсию” или заскучал поддерживать софт, то его работу продолжат те, кто в этом прямо заинтересован.
Часто бывает так, что проект технологии форкают (то есть делают клон исходного кода со 100% соответствием оригиналу, а затем развивают дальше, но уже под другим именем и свежими изменениями). В начале своей жизни форки совместимы со своими “родителями” и, по желанию новых разработчиков, подобная совместимость сохраняется достаточно долго.
Поэтому не стоит бросать изучение докера. Он очень сильно изменил индустрию и поэтому его еще долго будут хоронить, как пытаются похоронить PHP, openSUSE, Skype, обычную бумагу, флешки. И, возможно, он переродиться во что-то еще более крутое.
2018-01-04 12:49:47
Коротко об основных языках
PHP: Дорогая простота
Python: Непредсказуемая совместимость
NodeJS: Быстрая нестабильность
Go: Контролируемая паника
Java: Многословная переносимость
2017-12-25 20:54:53
Доступ к контенту (документы, аудио, видео, изображения) возможен только в приложении Телеграм.
2017-12-24 11:38:02
У вас не получается сделать что-то хорошо с первого раза? Не страшно. Отнеситесь к этому, как к созданию концепта. Ему вовсе не обязательно быть идеальным и работать на 100%. Важны архитектурные идеи и решаемая проблема. Вот например.
В 1967 году Уолтер Кронкайт (ведущий вечернего выпуска новостей CBS) представил концепт домашнего офиса, состоящего из модульной компьютернй системы. Модули: телефон и видеосвязь, "виджет" погоды, электронная почта, обмен документами и так далее. Все эти модули выглядели настоящей фантастикой в шестидесятых годах. Сегодня они есть в любом современном смартфоне как базовые функции. Догадывались разработчики и футуристы о том, что все их задумки можно будет носить в кармане брюк? Вряд ли.
В любом проекте важна идея и первый шаг. И нужно шагать широко — без страха совершить ошибку.
2017-12-24 11:37:51
Главное, чтобы команда чувствовала свою важность и ощущала результат в виде отчетов по реальным цифрам и фактам. Проще говоря, результат работы должен быть виден невооруженным глазом. В этом весь смысл
2017-12-16 19:35:49
Одна из основных проблем начинающих специалистов: в неумении расставить приоритеты. Эта проблема возникает из другой: сильное желание показать "на что способен". Строго говоря, если такому разработчику дать интересный проект (именно так обычно формулируют обещания HRы в вакансиях: "вы будете работать над интересным проектом". На вопрос что такое "интересный проект" я ни разу не слышал четкого ответа, даже от разработчиков)., то он застрянет в амбициях и потоке функционала. Программный продукт получается раздутым, но большая часть фич не работает от слова "совсем". Молодой специалист хочет в один заход впихнуть всё, чтобы поразить своего работодателя.
Главное вовремя разработчику сказать, что объем функционала и работоспособность функционала - это разные вещи. Продукт обретает ценность именно благодаря последнему. Иногда подобный сдвиг мышления долго не происходит, т. к. в коммерческой (заказной и особенно потоковой) разработке менеджеры проектов, желая поразить и выполнить все обещания заказчика (в надежде, что тот правда оценит труды и заплатит еще), продавливают фичастость против работоспособности. Мысли о том, что время не резиновое, обычно не возникает, что характерно.
Мне на днях рассказали про одну историю, которая неплохо иллюстрирует то, что я описал выше. Когда разрабатывали Google Chrome, то первая (и вообще-то единственная) функция была в том, чтобы самостоятельно скачивать обновления самого себя и устанавливать. Это было сделано местами очень криво, но оно работало и позволяло делать самое главное - быстро поставлять новые фичи. Приоритеты. Понимаете о чем речь? ;)
2017-12-13 12:07:15
Слово «дедлайн» появилось в Америке во время Гражданской войны: когда людей для охраны пленных не хватало, на земле рисовали круг и загоняли их туда. Всех, кто выходил из круга, расстреливали. Так и эти воины пера там, внизу, в холле: пленные сидят за линией смерти — дедлайном.
Это была цитата из бестселлера Ю Несбе "Снеговик".
Гражданская война давно закончилась, а некоторые разработчики дедлайна до сих пор боятся как смерти.
2017-12-07 19:38:15
Около трех недель назад, участники проекта eLama Junior Lab начали делать первые задачи на обучающей платформе и ровно неделю назад приступили ко второму этапу отбора на стажировку в eLama - самостоятельную разработку проекта. Разумеется, подобное задание выглядит чрезвычайно сложное для тех, у кого нет даже близко коммерческого опыта разработки. Задание должно показать возможности людей в абсолютно новой ситуации, а владение отдельными технологиями они приобретут уже на стажировке.
Сама идея обучающей платформы может быть описана метафорой "мороженое в вафельном стаканчике": все ее части можно использовать ("съесть без остатка") для обучения. Сейчас я объясню как это работает.
1. На платформе (которая, кстати, похожа на известный Codewars) можно решать алгоритмические задачи на Python, JS и PHP.
2. Платформа сама по себе не лишена недостатков. Те, кто их замечают, получают дополнительные балл к рейтингу. Если люди видят ошибки, значит они владеют знанием.
3. Мы допускаем "обход системы". И даже поощряем это. Если участник проявил любопытство, он получает пару баллов к рейтингу. Как говорится, "дали бумагу в линейку - пиши поперек".
Эти три пункта плюс аналитика кода, который пишут участники (а мы видим все, что они пишут, даже когда кто-нибудь отправляет неприличные изображения в виде ASCII-графики), помогает нам составить представление о будущем стажере. Кроме того, участников мы стимулируем обращаться к нам и задавать любые вопросы.
А если говорить о философии проекта eLama Junior Lab, то ее можно сформулировать так: образование - это фан.
#juniorlab
2017-12-04 13:03:23
Когда программист растет, его желания "делать мир лучше", "писать идеальные программы" и "максимально оптимизировать алгоритмы" постепенно уходят на второй план. На первом плане появляются такие вещи, как "решение бизнес-задачи", "довольный заказчик", "работающее ПО, которое можно поддерживать не надрывая спину". Решения конкретизируются и принимают форму, которую можно оценить простым критерием "работает/не работает". Нелюбимые языки становятся просто инструментами для решения проблем. Даже условий для успешного выполнения задачи становится меньше, т. к. главное у такого программиста уже есть: опыт и мозг.
2017-11-22 20:36:39
Эко-система проекта
Проекты, которые рассчитаны на долгосрочную поддержку, должны сформировать собственную эко-систему.
1. Уровень разработчиков
Здесь должен быть репозиторий с кодом, CI и внутренние правила по управлению версиями ПО. Желательно выбрать форму для релизов. Вхождение новых разработчиков должно быть дешевым (во всех смыслах этого слова).
2. Уровень менеджмента
Каркас управления проектом желательно выразить в виде простых правил: на уровне что можно и что нельзя, какие приоритеты расставлены. Нарисуйте схему вашего рабочего процесса. Если применяете Agile, убедитесь, что стратегические приоритеты всегда остаются неизменными, а не "скачут" из спринта в спринт. Не перемудрите.
3. Уровень коммуникации с пользователем продукта
Выберите хотя бы один способ обратной связи (электронная почта - предпочтительнее) на старте. Когда пользователей становится больше 1000, запускайте форум или тикет-систему. Сделайте так, чтобы отзывы были под вашим контролем - дайте людям площадку для выражения мыслей и чувств по отношению к продукту. Если вы не готовы отвечать на вопросы, не давайте людям ваши контакты.
4. Уровень качества
Тестируйте продукт. Проверяйте гипотезы улучшения. Эко-система должна облуживать получение качественного продукта. Если что-то мешает делать качественно, изменяйтесь. Чем больше гипотез улучшения качества вы проверите, тем лучше. Не все улучшения ведут к повышению качества.
2017-11-21 13:42:08