В 2017-2019 годах можно было наблюдать серьёзный рост TypeScript. Происходило это по вполне понятным причинам. В этом языке есть много хорошего. Почти половина респондентов исследования State of JavaScript 2018 года уже пробовали TypeScript и собираются писать на нём в будущем. TypeScript весьма популярен, но стоит ли использовать его в крупномасштабных программных проектах?



В этом материале предпринята попытка достаточно строго, опираясь на числовые показатели и практический опыт автора, проанализировать эффект от использования TypeScript при разработке больших проектов.

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



Итак, перед вами часть третья, и на данный момент последняя, о похождениях блудного попугая программиста. В первой части я уехал жить и работать на Кипр. Во второй части я пытался устроиться в Google и переехать в Швейцарию. В третьей части (вот этой самой) я устроился на работу и переехал в Нидерланды. Сразу скажу, что про поиск работы будет мало, так как его фактически не было. В основном будет про обустройство и жизнь в Нидерландах. В том числе про детей и покупку дома, что не было подробно описано в недавних статьях других авторов.

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

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

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

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

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

Каждый раз перед собесом я говорю себе: "Спокойно, не нужно ничего выдумывать, доучивать и врать, твоих знаний и опыта достаточно для того, что бы работать у них. Ты усилишь любую команду, тебе есть что предложить, а пробелы в твоих знаниях — приемлемы. Если бы они знали о твоих навыках всё, что знаешь ты, они бы точно тебя взяли". Но когда начинается собеседование, я всегда перестаю в это верить. Все два часа интервью я хожу как по минному полю, что бы не дай бог не спалиться, что я чего-то не знаю.

Во первых словах:

— Работа программистом-разработчиком — тяжелый труд, сравнимый с валкой леса топором. И проблематика данного труда сильно недооценена в общественном сознании.

Сейчас я обосную этот тезис с научной точки зрения.

Вашему вниманию предлагается перевод поста Гергелия Ороса, занимающего должность Engineering Manager в Uber. В нем он делится своим взглядом на проектирование крупномасштабных систем, основанном на собственном практическом опыте работы в Uber и Microsoft. В сочетании с комментариями на Hacker News, которые добавляют весомые контр-аргументы и дополняют точку зрения автора, его статья стала одним из самых интересных постов недели. В статье используется термин «дизайн кода» для сравнения с традиционной «архитектурой» — о нем подробнее можно прочитать здесь.

На мою долю выпало достаточно опыта в проектировании и создании крупномасштабных систем. Я принимал участие в переписывании распределенной системы платежей в Uber, проектировании и релизе Skype на Xbox One и выпуске в открытый доступ RIBs — мобильного архитектурного фреймворка, созданного в Uber. Все эти системы имели тщательно продуманный дизайн, прошли через несколько итераций, с ними связано множество совещаний, проведенных у маркерной доски, и других обсуждений. Затем придуманный дизайн сводился к дизайн-документу, который распространялся среди других разработчиков для сбора дополнительной обратной связи, который продолжался до тех пор, пока мы не переходили к разработке.

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

Всем привет, дорогие друзья! Вот сижу, смотрю на бесконечную простыню кода, провожу ревью с баночкой ред була. Прошел год. Год, блин, всего лишь год — так много и так мало одновременно. На этот год у нас были наполеоновские планы, и сейчас кажется, что мы мало что успели. С другой стороны — нам удалось сделать кое-что, что достойно войти в анналы айти с пометкой «Слабоумие и отвага». Я бы назвал эту историю «Как запилить свой движок с тулзами и рендером с нуля всего за год». Издание выйдет на несколько томов, но куда деваться, надо с чего-то начинать. Так что погнали!

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

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

• TDD — ну, это все знают, сначала пишем тесты, а потом остальной код.
• BDD — что-то знакомое, вроде как, тоже тесты, но особенные.
• TDD — снова? Так, стоп, тут речь уже не о тестах совсем. Но почему называется так же?
• DDD — bound contexts, ubiquitous language, domain...
• FDD — да сколько можно?
• MDD — cерьезно, на основе диаграмм?
• PDD — ...

Подходы к разработке делятся по сложности, областям применения и целям.
Думаю, настало время разобраться, зачем же они нужны, почему их так много, и как они могут быть нам полезны.

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

Привет, я Катя, я не работаю уже год.



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

Не так давно я работал контрактником, перескакивая с одного проекта на другой. С некоторыми краткосрочными проектами справлялся за неделю. Другие длились пару месяцев. Они приносили достаточно денег, чтобы взять отпуск. Но я предпочитал короткие, потому что там можно было установить бóльшую часовую ставку. Я не только сам себе хозяин, но и не приходилось слишком много работать, чтобы зарабатывать на жизнь. Даже мои самые высокие ставки были вполне разумными, и я всегда обеспечивал высокое качество обслуживания. Так было до тех пор, пока мне не предложили контракт в большой компании.

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

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

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

Vue.js содержит много интересных и необычных подходов к валидации, которые помогут решить ваши проблемы. Обзор под катом!

Итак, вы решили сделать новый проект. И проект этот — веб-приложение. Сколько времени уйдёт на создание базового прототипа? Насколько это сложно? Что должен уже со старта уметь современный веб-сайт?

В этой статье мы попробуем набросать boilerplate простейшего веб-приложения со следующей архитектурой:

Что мы покроем:

• настройка dev-окружения в docker-compose.
• создание бэкенда на Flask.
• создание фронтенда на Express.
• сборка JS с помощью Webpack.
• React, Redux и server side rendering.
• очереди задач с RQ.

Привет, Хабр! Представляю вашему вниманию перевод статьи Саманты Коул (Samantha Cole) c motherboard.vice.com.

Анонимные специалисты по машинному обучению написали «статью про минет», чтобы сделать эту машинку для отсоса более реалистичной.

Autoblow AI, секс-игрушка для пользователей с пенисом, состоит из резинового рукава и расположенного внутри корпуса электродвигателя, и пытается имитировать оральный секс. Ее кампания на Indiegogo была запущена на прошлой неделе и быстро достигла своей цели в 50 000 $. Ее главное преимущество над предыдущей моделью, Autoblow 2, выпущенной в 2014 — это алгоритм машинного обучения, который «постоянно меняет технику», чтобы удовлетворить пользователя новыми способами.

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

JavaScript нередко называют «самым популярным языком», но, кажется, никто не отзывается о JS-разработке как о «самой безопасной», и количество подстерегающих проблем в экосистеме велико. Как эффективно их обходить?



Илья Климов задумался об этом, когда ошибка обошлась очень дорого (в буквальном смысле) — и в итоге сделал доклад на HolyJS. А поскольку зрительские отзывы оказались отличными, мы теперь подготовили для Хабра текстовую версию этого доклада. Под катом — и текст, и видеозапись.

24 февраля — день рождения легендарного разработчика игр. Ему стукнуло 65 лет.
Поздравляем!

«В течение всего долгого пути вы просто обречены на ошибки, и это хорошо», – говорит он. – «Нужно ошибаться и каждый раз извлекать из этого новый опыт. Нужно совершить несколько ошибок. Наверное, в этом весь секрет. У меня есть жёсткий диск, забитый прототипами, так и не прошедшими в стадию производства. Не всякая идея хороша, но вы должны учиться на своих ошибках больше, чем на успешных результатах. Так что будьте готовы к провалу, будьте готовы пробовать что-то новое и просто продолжайте делать игры. Мы падаем каждый день, но каждый раз вновь поднимаемся».

Спасибо, Сид, за счастливое детство, когда с дискеты в оперативку 286-го загружали первую циву (не было HDD) и гоняли зулусов вместо написания программ на LOGO.

Исчерпывающая биография Сида есть на Википедии. Я же подсуетился и собрал в одном месте все материалы про Сида Мейера на русском.

Дисклеймер: По-моему, статья об архитектуре ПО не должна и не может быть идеальной. Любое описанное решение может покрывать необходимый одному программисту уровень недостаточно, а другому программисту — слишком усложнит архитектуру без надобности. Но она должна давать решение тем задачам, которые поставила перед собой. И этот опыт, вместе со всем остальным багажом знаний программиста, который обучается, систематизирует информацию, оттачивает новыки, и критикует сам себя и окружающих — этот опыт превращается в отличные програмные продукты. Статья будет переключаться между художественой и технической частью. Это небольшой эксперимент и я надеюсь, что он будет интересным.

— Слушай, я тут придумал отличную идею игры! — гейм-дизайнер Вася был взъерошен, а глаза — красные. Я ещё попивал кофе и холиварил на Хабре, чтобы убить время перед стенд-апом. Он выжидательно посмотрел на меня, пока я закончу писать в комментариях человеку, в чем он не прав. Вася знал, что пока справедливость не восторжествует, а правда не будет защищена — смысла продолжать со мной разговор нету. Я дописал последнее предложение и перевел на него взгляд.

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

Он убежал по своим гейм-дизайнерским делам, а я — открыл IDE.

Данную статью я написал, основываясь на своем личном опыте, поэтому все что упомянуто в ней, я опробовал сам!

Почему я вообще решил написать об этом? Боль в спине!

Важно рассмотреть этот вопрос достаточно глубоко потому, что это касается не только физического здоровья, но и радости, благополучия в семье, успеха в делах, внутренней энергии, а значит и работоспособности, и даже долголетия! (а ведь хочется на пенсии подольше наслаждаться хорошим самочувствием, а значит и здоровьем)

Здоровье до того перевешивает все остальные блага жизни, что поистине здоровый нищий счастливее больного короля — Артур Шопенгауэр

А чем вообще мы занимаемся на работе, в физическом плане?

Водим мышкой и «тычем кнопки»

В общем, прости нас, запястье. Вы спросите почему? Да потому, что со временем оно начинает жутко болеть, доставлять кучу неудобств, и даже ронять предметы. (У моей бабушки именно так, водила она не мышку, а кисть.)

Молчу уже про туннельный синдром.

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