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

Эта статья — вольный пересказ доклада, который я посетил на конференции GOTO Berlin 2017: A Crystal Ball to Prioritize Technical Debt.

Изображения из доклада и права на них принадлежат автору @AdamTornhill.

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

Но как формализовать понятие технического долга, чтобы объяснить его другим? И, тем более, объяснить это менеджеру так, чтобы получить одобрение на рефакторинг? Как найти все места в проекте, которые нужно по-хорошему переписать, и как определить, какие из них должны быть переписаны в первую очередь?

Если эти вопросы неоднократно у вас возникали, прошу под кат.

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

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

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

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

С ЭВМ (слово компьютер тогда не было в ходу) я столкнулся в году 1977, просто курс такой был на мехмате. Fortran IV, коды М-20, Algol-60, PL/1, сразу после универа попал в программисты (системные программисты!), и пошло-поехало…

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

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

Привет, Хабр.

Во второй части были рассмотрены 5 способов использования Raspberry Pi. И как оказывается, этот микрокомпьютер способен ещё на большее. Сейчас мы рассмотрим еще 5, надеюсь, не менее интересных возможностей Raspberry Pi.



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

В книге ”Masters of Doom” о компании id Software и её влиянии на массовую культуру Дэвид Кушнер размышлял о необычном стиле работы ведущего программиста Джона Кармака.

Чтобы повысить производительность и не отвлекаться от работы над движком Quake, тот принял агрессивный подход — начал постепенно смещать начало рабочего дня. В конце концов Джон садился программировать вечером, а заканчивал перед рассветом. Эти непрерывные отрезки тишины, изоляции и глубокой работы позволили ему создать первый в мире сверхбыстрый 3D-движок. Игра Quake произвела настоящий фурор.

Подписывайтесь на каналы:
@AutomotiveRu — новости автоиндустрии, железо и психология вождения
@TeslaHackers — сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla



Количество строк кода в современном автомобиле в 200 раз больше чем в Шаттле, в 60 раз больше, чем в истребителе F-22 Raptor, в 50 раз больше, чем в телескопе Хаббл, в 20 раз больше чем в марсоходе Curiosity, в 4 раза больше чем в истребителях пятого поколения, в 2 раза больше, чем в большом адронном коллайдере или Facebook, если распечатать весь код на бумаге, то стопка будет высотой 200 метров. (по данным на 2009-2012 год)

Данные по количеству строк кода в современном автомобиле вызвали бурные споры на Reddit. Вопросы на темы от «В каком месте эти строчки прячутся, если у микроконтроллеров ограничена память?» до «Разве количество строк кода хоть что-то значит?»

Сравнительные данные по количеству строк кода (SLOC) в различных проектах довольно интересные.

Изучение истории дисков — начало пути к пониманию принципов работы твердотельных накопителей. Первая часть нашего цикла статей «Введение в SSD» проведет экскурс в историю и позволит наглядно понять разницу между SSD и его ближайшим конкурентом — HDD.

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

Отдельное внимание следует обратить на единицу измерения вместимости накопителей: исторически сложилось, что десятичные приставки, такие как кило- и мега-, в контексте информационных технологий подразумевают как десятая и двадцатая степень двойки. Для исключения путаницы были введены двоичные приставки киби-, меби- и другие. Разница этих приставок становится заметной с увеличением объема: покупая диск на 240 гигабайт, вы можете сохранить на нём 223.5 гибибайта информации.

Кто из нас не ронял продакшн, не обнаруживал, что база побилась, а бэкапов нет, не обваливал работу системы перед демо коммитом «ну сейчас рюшечку поправлю только, она же точно ничего не поломает», не выкатывал на всю аудиторию мобильное приложение со 100%-воспроизводящимся критичным багом, не обнаруживал продакшн-сервер взломанным, да мало ли бывает замечательных действий… Некомфортная ситуация влияет на наше состояние, не дает принимать взвешенные решения, заставляет поступать так, как в спокойной обстановке мы бы не поступили — только диву даешься, как же вот этого не увидел или вот этого не сделал. И хочется разобраться, что же происходит, понять, как лучше в следующий раз и вообще научиться с ним справляться. Как? В статье мы с AlbinoKoala систематизировали свой опыт и даже прочитали митап перед коллегами.

Меня зовут Олег, я работающий удалённо DevOps-инженер в компании «Флант», и в этой статье я постараюсь убедить вас в том, что занятия бегом — лучший выбор для удалёнщика.

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

Настало время релиза Evolution CMS 2.0 RC на компонентах Laravel 6.0, но как показал предыдущий релиз и последующие за ним обсуждения — существует масса вопросов и мифов связанных с веткой 2.0.

Самый популярный миф — в новой ветке все изменилось и по-старому уже не будет.

Неправда — будет и по-старому. Основное отличие в том, что сохранив возможности “по-старому” мы добавили возможности и “по-новому”. Уровень входа не изменился, но более продвинутые разработчики получат много готовых решений и возможностей, а те кому достаточно существующих компонентов могут работать также, как и раньше, никто не будет никого лишать привычных вещей.

Уровень совместимости максимальный — даже с версии 0.9 вы можете обновиться до 1.4, а с нее до 2.0 при сохранении функционала. Хотя надо учитывать возможные проблемы которые могут возникнуть с depricated методами из за того что нужно поднять версию php до 7.2, но скорость работы того стоит, а реагировать на эти баги буду быстро, чтобы приблизить срок стабильного релиза.

Однажды, в понедельник, мне пришла в голову мысль — "а покопаюсь ка я в новом ядре" (новым относительно, но об этом позже). Мысль не появилась на ровном месте, а предпосылками для нее стали:

• тестовое задание, от одной из крупных студий матушки-России (в котором фигурировала аббревиатура ORM),
• идея написать простенький модуль,
• желание одного из клиентов, в перспективе, сделать магазин.

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

Никак не можете найти ту самую ссылку на цветовые профили для Wireshark? Забыли, на каком сайте видели удобную стойку для Site Survey? Какой адаптер подходит для Packet Capture на Windows? Закладка с таблицей модуляций осталась в другом браузере?

Мы тоже от этого устали.

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

Ровно 15 лет назад, в этот самый день, своими дрожащими коленками я переступил порог офиса небольшого провинциального интернет-провайдера. Моя первая настоящая работа в качестве программиста. Знаний почти нет. Тонкий испуганный голосок откуда-то из желудка советует развернуться и убежать подальше, пока окончательно не опозорился. Глубокий вдох-выдох, и вот генеральный директор уже ведет меня в небольшую комнатку-подвальчик, показывает на полуразобранный компьютер, видавший лучшие времена: «Это твое рабочее место. Устраивайся». Так началась моя карьера.

Но перенесемся в настоящее. Сейчас я пишу эти строки, сидя в удобном офисе престижного БЦ в центре Москвы. За плечами работа с крупными международными брендами и разработка сложных fintech приложений. Сотни книг прочитано и десятки статей написано. Мания величия давно вылечена. Менеджерские позиции опробованы и отвергнуты. Душевное равновесие найдено. Любовь к профессии сохранена. Однако это не статья из серии “Какой я молодец. Делай, как я и тоже будешь молодцом”. Эта статья о том, какие ошибки я совершал и что можно было сделать лучше. Эта статья — ретроспектива моей карьеры.