История о воробушках, правильном фидбеке и житейских проблемах/

В 1958 году Мао Цзэдун инициировал «Большой скачок» — организованную китайской коммунистической партией кампанию по трансформации страны в индустриально развитое государство.

Акция «Четыре зла» входила в число первых шагов, предпринятых в рамках «Большого скачка». Под девизом «Человек должен победить природу» власти нацелились на уничтожение четырех вредителей: крыс, мух, комаров и воробьев.

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

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

«Я хочу творить, а не быть следствием чужого творчества. Я хочу принадлежать к тем, кто создает смыслы, а не быть плодом этого смысла».

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

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

Буквально на днях ISPsystem исполнилось 20 лет. Дата серьезная, основательная.

«А почему бы не вспомнить, как всё начиналось?» — подумали мы и собрали совет старейшин. Тех, кто «был там 3000 лет назад» и застал времена, когда DevOps’ом в мире и не пахло, автоматизацию делали кастомными скриптами, а разработчики порой экспертиментировали прямо на проде.

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

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

...И еще несколько историй прямиком из моего шкафчика со старыми футболками

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

Я подозревал, что за годы работы в Amazon, Microsoft и Google у меня скопилась богатая коллекция футболок, свитеров, толстовок и курток, но лишь занявшись их сортировкой, я осознал, как их на самом деле много (около трех десятков!).

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

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

Предлагаем немного окунуться в прошлое и посмотреть, какую электронику предлагали каталоги в 70-х, 80-х и 90-х годах прошлого века.

Осторожно: много картинок!

Немного личных впечатлений от IBM PC XT и Amstrad PC1640 — как это было в 80-е.

Оригинальный компьютер IBM PC был выпущен в 1981 году и с первых дней ему сопутствовал успех. Помимо звучного названия IBM, имелись и более серьёзные причины его популярности. Среди основных можно назвать открытые стандарты и наличие слотов расширения.

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

За время работы в Google я провёл более двух сотен интервью. И главное, что я вынес из этой работы — проводить качественные собеседования очень непросто. Все дело в сигналах, которые мы посылаем и получаем. И у интервьюера, и у самого кандидата есть меньше часа, чтобы выложиться на полную. Порой, по разным причинам, мы получаем друг от друга ложные или неточные сигналы. Такова уж человеческая природа.

С годами я выработал вопрос по кодингу, который мне самому очень нравится. Это до жути простой и в то же время заковыристый вопрос. Решение занимает не более 30 строк кода, но зато даёт мне все нужные сигналы для вынесения верной оценки кандидату. Кроме того, мой вопрос отлично масштабируется и подходит как стажёрам, так и опытным инженерам. Здесь я не стремлюсь доказать, что мой вопрос лучше какого-то другого. Я лишь хочу объяснить, как он помогает мне как интервьюеру и на что я обращаю внимание на собеседовании по программированию.

В этой статье будут вещи, с которыми вы можете не согласиться. Это нормально. Это просто моё мнение, а так как я уже вышел на пенсию, то больше не представляю опасности ни для интервьюеров, ни для инженеров Google при принятии решений о найме! ;-)

История о том, как мой 12-летний ThinkPad за $200 пережил два элитных MacBook’а.

Что это за ноутбук на фото? Это самый неубиваемый, способный непрерывно работать и при этом не желающий умирать компьютер из всех, что у меня были.

Впрочем, довольно. На этом пока остановимся.

Я не поленюсь написать о нём весь этот пост, а вкратце скажу так.

Вам нужен современный, привлекательно выглядящий, легкий и мощный ноутбук? Купите что-нибудь дорогостоящее от Apple или Microsoft.

А если вам нужно кое-что другое? То, что не будет стоить почти никаких денег и прослужит до тех пор, пока не погаснет солнце? Тогда возьмите старый, подержанный ThinkPad.

Привет, Хабр! Меня зовут Ксения, я руководитель отдела QA в компании ISPsystem. О том, как я собирала команду, можно почитать в моей предыдущей статье. 

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

Кто же отвечает за качество продуктов и каким образом QA-инженеры могут на него влиять? Я опросила лидов, проджектов и продактов всех команд нашей компании об ожиданиях от QA. В своей статье хочу поделиться итогами опроса и подсветить, в каких моментах ожидание и реальность не совпадают. А еще — рассказать, как результаты опроса помогли найти точки роста для нашего отдела.

Кто такой QA

Как я уже говорила, обязанности и задачи QA-специалиста могут разниться от компании к компании — все зависит от принятых процессов. Где-то роль QA-инженера может совмещаться с другой ролью, например системного аналитика или специалиста техподдержки. А где-то сотрудники могут заниматься исключительно приёмочным тестированием, что характерно для роли обычного тестировщика. Я расскажу, чем занимается отдел QA в нашей компании. Но для начала кратко опишу принятые у нас процессы и на каких этапах к ним подключаемся мы. 

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

Я работаю программистом уже почти десять лет. И, как и для каждого, кто посвящает работе до 2/3 суток, удобный инструментарий имеет для меня огромное значение. Сегодня я хочу как следует порефлексировать, поэтому статья выйдет слегка необычной. Сразу же хочу дать дисклеймер: всё, что вы прочтете ниже, носит субъективный характер. Поэтому будьте открыты и снисходительны.

Привет! Меня зовут Екатерина Юлина и я руковожу UX/UI-отделом в компании ISPsystem с января 2022 года – сейчас у меня в штате 5 продуктовых дизайнеров уровней junior, middle и senior. Когда я принимала под управление отдел, меня озадачили низкий уровень мотивации сотрудников и отсутствие у них системного подхода к развитию.

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

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

Мы с Мэттом сидели друг против друга и беззаботно болтали о технологиях и готовке. Раньше мы были шапочно знакомы по Twitter, где он постил разные кулинарные фото. Я даже стал немного завидовать ему и другим жителям пригородов, их мощным газовым горелкам для воков на заднем дворе. Мэтт выступает в качестве «подопытного» в моем новом проекте. Благодаря ему я смогу понять, интересную ли штуку придумал, или игра не стоит свеч.

– А кем ты работаешь?

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

– А до того?

– Инженер-геолог. Куча горных работ, разные туннели. Гидроэлектростанции. Земляные насыпные плотины – их часто строят рядом с шахтами.

Он рассказал мне о своей старой работе. Его фирму наняли для исследования системы разработки рудника в Британской Колумбии (провинция на западе Канады – Прим. пер.) методом блокового обрушения. Блоковое обрушение – это такой способ разработки шахты, при котором под месторождением роют туннели, чтобы его дестабилизировать. Месторождение медленно обрушается, а руда ссыпается в специальные отводы. «А деньги падают в карман, будто ты их на принтере печатаешь», – добавил Мэт. В чем подвох? Шахта залегала в четырехстах метрах под свалкой токсичных отходов конкурирующей компании. «Может ли статься, что в случае землетрясения отходы затопят шахту и всех умрут?» Мэтту нужно было доказать, что всё в порядке.

Согласитесь, его нынешняя работа – совсем другое дело. «Мой скромный блог куда безопаснее, чем всякие проекты по добыче полезных ископаемых стоимостью в сотни миллионов долларов».

Кажется, моя идея была не так уж плоха…

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

В день окончания колледжа один из лучших друзей подарил мне экземпляр книги доктора Сьюза «Oh, the Places You'll Go!». Поскольку мое детство прошло за пределами Соединенных Штатов, я умудрился прожить 21 год, понятия не имея, кто такой доктор Сьюз. Так что поначалу я был в замешательстве. Почему друг подарил мне комикс с дурацким текстом и странными рисунками? В тот день много чего случилось, поэтому я вежливо улыбнулся и положил книгу в кучу с другими подарками. Лишь спустя пару дней у меня нашлось время, чтобы прочитать её от корки до корки. Эта книга — шедевр, и это однозначно лучший подарок, который можно сделать любому выпускнику.

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

Как минимум, это касается коммерческой стороны вопроса. Предположим, вы решили купить игрушку, выпущенную лет двадцать-тридцать  тому назад. Например, это может быть любимая игра вашего детства или, наоборот, что-то неизведанное, о чем вы недавно узнали на форуме ретро-геймеров! Как бы то ни было, первым делом вы наверняка отправитесь на GOG, в Steam или Epic Games Store. И, как это ни прискорбно, в 9 из 10 случаев вы столкнетесь с тем, что игра «зависла» между мирами: правообладатель до сих пор не отправил ее в «свободное плавание» и запрещает распространять бесплатно, но при этом сам поленился разместить игру на одном из популярных маркетплейсов.

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

В одно прекрасное воскресенье, потягивая пиво и размышляя о жизни, я вдруг подумал: а можно ли вместить JavaScript-реализацию игры «Жизнь» в один твит? И не смог устоять перед желанием попробовать свои силы. 

Задумывались ли вы когда-нибудь о том, как жилось веб-разработчикам 20+ лет назад, когда всемирная паутина была явлением совершенно новым, а чтобы войти в неё, приходилось некоторое время слушать специфические звуковые сигналы, JavaScript и CSS воспринимались скорее как диковинка, а не как привычные средства разработки веб-сайтов, а самым популярным браузером был Internet Explorer? Что ж, вероятнее всего, нет... Но, если у вас найдется несколько свободных минут и вы захотите разобраться в очередной бесполезной штуке — эта статья вас не разочарует!

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

На дворе 2023 год. У нас есть доступ к количеству информации, которому позавидовала бы любая, даже самая пухлая энциклопедия. Тем не менее, технические специалисты до сих пор склонны искать серебряную пулю, которая одним махом решит все их проблемы. Их одинаково много: и тех, кто ищет, и тех, кто думает, что нашел.

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

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

Эта статья — призыв к самосовершенствованию. У вас все получится. Станьте инженером.

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

Что же такое фреймворки? Фреймворки — это инструменты разработки ПО, которые обеспечивают базу для реализации проектов определенного типа. Так, если вам нужно написать одностраничное веб-приложение на TypeScript, необязательно делать это с нуля, ведь есть Angular. Хотите заняться машинным обучением на Python? Позвольте представить вам моих друзей Scikit-Learn и Keras. Хотите построить бэкенд на C#? (О боже, вы чертовски круты.) Уверен, вы уже знакомы с ASP.NET. Можно продолжать эту мысль на протяжении еще 1500 слов, но вы и так все прекрасно поняли.

Зная какой-либо фреймворк, вы сможете получить должность, в названии которой есть слово «инженер» и, возможно, «машинное обучение». Если вы владеете двумя фреймворками, то запросто устроитесь на вакансию, в заголовке которой будет присутствовать словосочетание «full stack». Однако если вы собираетесь добиться успеха на следующей работе — той, на которую вас примут, потому что в вашем резюме указано 3-5 лет «инженерного» опыта, — ваш набор навыков должен быть гораздо глубже, нежели знание парочки фреймворков. Иначе нервы у вас сдадут еще на этапе прохождения испытательного срока.

Это похоже на путешествие. Из фреймворкеров в программисты, из программистов в инженеры. Взглянем на каждую из этих ступеней. Я расскажу о каждой из них и о том, как должен выглядеть профессиональный рост на данной ступени.

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

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

Для ясности, это вовсе не пережитки прошлого, а действующие сайты, которые — в большинстве случаев — обновлялись в 2023 году.