Введение

это сборник мыслей о разработке программ собранный разработчиком с мозгом груга

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

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

разработчиков с большим мозгом много, некоторым страница не понравится, скривят кислая рожа

Ещё больше-больше ДУМАЮТ, что они разработчики с большим мозгом и им она тоже не понравится

(груг раньше думал груг с большим мозгом, но потом всё понял)

это ладно!

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

Я живу на периферии технологической тусовки. И на периферии в географическом смысле. А это значит, что:

• Я никогда не был на профессиональных конференциях. Просто потому, что никогда не предоставлялось такой возможности.
• Я никогда не покупал обучающие курсы: для меня странно платить за то, что можно изучить самому в этих ваших интернетах или по книгам. Заманчиво, конечно, получить концентрированные знания, подкрепленные выполнением практических заданий, заполучить сертификат. Но на это у меня никогда не было ни средств, ни времени.
• Я адепт цифрового аскетизма: не по своей воле, но как порождение вечной перестройки в нашей стране. В короткие периоды финансовой стабильности я обновляю электронику по остаточному принципу. Вот и сейчас пишу этот текст на Core2Duo десятилетней давности. Все еще жду следующего стабильного плато на кривой моих доходов.
• Раза три в своей жизни я покупал игры. В 90-е. Это были кассеты для отживающего своё Спектрума. На покупку ПО я смотрю с удивлением: когда все пользовались пиратским ПО, то и я пользовался, не понимая сути вопроса. А потом, в начале двухтысячных, полностью перешел на Linux и покупать стало нечего.

За пять дней, с 24 по 28 июля 2017 года, я прошел собеседования в LinkedIn, Salesforce Einstein, Google, Airbnb и Facebook; все пять компаний предложили мне работу. Это был замечательный опыт и я понимаю, как мне повезло, что мои усилия оправдали себя, поэтому решил написать об этом. Здесь я расскажу о том, как готовился к собеседованиям, как они проходили и какое впечатление произвели на меня компании.

Как все началось

Я отработал в Groupon почти три года. Это моя первая работа, там были и прекрасные люди, и отличные проекты. Мы делали всякие интересные штуки, вводили перемены внутри компании, публиковали материалы и все в таком духе. Но со временем я стал ощущать, что темп моего самообразования стал затухать (попросту говоря, замедляться), мне не хватало пищи для ума. К тому же, как и всякого разработчика ПО из Чикаго, меня тянуло в Область залива Сан-Франциско — ведь там столько известных компаний.

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

После того, как я изложил свою историю «трудоустройства» в Яндекс в комменте к нашумевшей заметке «Как я проработала 3 месяца в Я.Маркете и уволилась», было бы несправедливо утаить и ту пользу, которую я вынес из своего опыта Яндекс.Собеседования.

В мои рабочие обязанности входит техническое интервьюирование кандидатов на позицию Fullstack JavaScript/TypeScript Developer, активно этим делом (стоит ли говорить, что слегка поднадоевшим?) я занимаюсь больше года, за плечами более 30 технических интервью.

Раньше на техническом интервью я задавал кандидату довольно бестолковые вопросы аля «что такое замыкание», «как в JavaScript реализуется наследование», «вот есть такая-то таблица в БД с такими-то индексами, расскажите, пожалуйста, как можно ускорить такой-то запрос», которые хоть и помогали выявить инженерные способности кандидата, но совершенно не позволяли сделать вывод о том, насколько хорошо человек сможет решать задачи и насколько быстро он сможет разобраться в уже существующем коде. Что не могло не привести к печальным последствиям…

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

На сегодняшний день множество IT-компаний сталкиваются с проблемой поиска сотрудников в своем регионе. Все больше предложений на рынке труда связаны с возможностью работы вне офиса – удаленно.

Работа в режиме full-time remote предполагает, что работодатель и работник связаны четкими трудовыми обязательствами: контрактом или трудовым договором; чаще всего, определенным нормированным графиком работы, стабильной зарплатой, отпусками и прочими особенностями, которые зачастую присущи тем, кто проводит свой рабочий день в офисе.
Преимущества постоянной удаленной работы для каждого, кто решил оставить офис, свои. Возможность работать на крупные зарубежные компании без переезда в другой географический регион, стабильность, в сравнении с freelance – это, наверное, основное, что может привлечь нашего соотечественника. Высокий уровень конкуренции – вот основная сложность, с которой сталкивается соискатель, выходя на поиски работы на международном рынке труда.

*почти

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

Volvox

В начале 1960-х Ричард Фейнман давал несколько лекций для студентов, позже собранных в книгу "Фейнмановские лекции по физике". В книгу не вошла лекция по планетарному движению, но найденные позднее заметки позволили Дэвиду Гудштейну, коллеге Фейнмана, написать о ней книгу: "Потерянная лекция Фейнмана" [David Goodstein, Feynman’s Lost Lecture]. Цитата из книги, опубликованной в номере журнала Caltech’s Engineering & Science 1996 года:

Фейнман был великим учителем. Он гордился способностью придумывать способы объяснять самые глубокие идеи начинающим студентам. Однажды я сказал ему: «Дик, объясни мне так, чтобы я понял, почему частицы с полуцелым спином подчиняются статистике Ферми-Дирака». Фейнман сказал: «Я подготовлю лекцию для первокурсников на эту тему». Но через несколько дней он вернулся и заявил: «Я не смог. Я не смог низвести это до уровня первокурсников. Это значит, что на самом деле мы этого не понимаем».

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

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

Здравствуйте. Мы производим металлические изделия. Штамповка, сварка, покраска, упаковка. Год назад я познакомился с «Теорией ограничений» (далее ТОС). И попытался представить, как теорию из книг можно применить на практике. Деревья, диаграммы, тучи и прочие термины этого учения никак не укладывались в русский менталитет производственника. Почему русский? Потому что в России, все методики (ТОС, «Бережливое производство» и т.п) плохо приживаются на предприятиях. И не нужно говорить, что есть удачные проекты. Да, они есть. Но чем ниже по служебной лестнице находится работник, тем его отношение к этим нововведениям хуже. Ниже — хуже. Дело в том, что такой работник не видит картины в целом. Да и ему не надо. Не его это забота. Сказали карточки клеить на ящик, значит, будем клеить, а то премии ещё лишат. Задача грамотного руководителя брать от каждой теории что-то очень ценное. То, что можно применить, используя простые алгоритмы и методы вычисления.

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

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

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

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

Современные web-приложения зачастую содержат множество "движущихся частей" и сторонних зависимостей. В процессе рефакторинга и добавления/изменения функциональности в таком приложении может произойти поломка существующих use-case сценариев и нестабильная работа в определенных браузерах.

Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:

• https://devexpress.github.io/testcafe/
• http://nightwatchjs.org/
  

Быть программистом — это призвание? Возможно. Мы в 1cloud решили выяснить, как сами программисты оценивают свои достижения, какие качества считают неотъемлемыми в своей работе (вне зависимости от выбранного языка и специализации) и какие советы дают начинающим разработчикам.

Содержание

1. Введение в Computer Science
2. Структуры данных и Алгоритмы
3. Системное программирование
4. Распределенные системы
5. Базы данных
6. Объектно-ориентированный дизайн и разработка софта
7. Искусственный интеллект
8. Машинное обучение
9. Веб-разработка и интернет-технологии
10. Concurrency
11. Компьютерные сети
12. Разработка мобильных приложений
13. Математика для программистов
14. Теория информатики и языки программирования
15. Архитектура компьютера
16. Безопасность
17. Компьютерная графика
18. Работа с изображениями и компьютерное зрение
19. Интерфейс Человек-Компьютер
20. Вычислительная биология
21. Прочее

Не поймали за хвост удачу в виде главного бага известного сервиса, нет желания “толкаться” на oDesk или не хочется делать то же, что уже и так делаете в рабочее время?

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

^{К пятой продлёнке дети научились вполне серьёзно троллить выступающих}

Мы делаем открытые уроки про разные профессии – делали про кондитеров, генетиков, космонавтов. Каждый раз приходили живые представители профессии и рассказывали о своей работе. Первая продлёнка про программистов получила просто сумасшедшие отзывы, поэтому мы сделали ещё одну – но на этот раз не про код, а про самые разные профессии в ИТ.

Ниже – короткие выдержки из рассказов Натальи Касперской из Infowatch, Сергея Орловского из Nival и Василия Лебедева из RedKeds. Простыми словами о будущем для детей. Целая куча интересных профессий!

Есть три способа описания процесса:







Чем они отличаются?

Описание сущего

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

Природа пространства-времени

Начнем с того, что воспринимаемый нами мир – это четырехмерное пространство-время. Но не то пространство-время, которое используют математики в своих рассуждениях. Скорее это то пространство, которое используют физики. Разница в том, что в физическом мире нет точек. Есть объекты, которые с точки зрения наблюдателя можно считать точечными. Но при ближайшем рассмотрении эти точки могут рассматриваться как бесконечные пространства. Мы часто не различаем воспринимаемый нами мир и математическую абстракцию, созданную для описания этого восприятия. В абстракции, созданной для описания воспринимаемого мира, есть понятие точка. В реальном мире нет точек. В этом огромная разница между моделируемым миром и его моделью. В неразличении этих двух сущностей кроется причина части холиваров, возникших на основе предыдущей статьи. Например, мы не способны воспринять срез пространственно-временного континуума поперек временной оси, как нам предлагает поступить ИСО 15926, для определения понятия событие. Поэтому далее я продолжу рассуждения, не отвлекаясь на такие понятия как точки, срезы пространственно-временного континуума и прочие абстрактные объекты. Мы будем работать только с реально воспринимаемыми нами объектами 4-Д пространства-времени.

Нижеизложенный материал не претендует на оригинальность или новизну решаемой проблемы, но может быть крайне полезен новичкам и тем, кто как и я, заботится о сохранности своих данных на устройствах под управлением Android. Далее в статье я ставлю перед собой задачи по обеспечению надежного резервирования данных при помощи облачных сервисов хранения данных и решаю их. Все еще интересно? Тогда добро пожаловать под хабркат.

Это вольный перевод-пересказ этой статьи 2006 года, на которую я наткнулся около mailinator.com, за авторством Paul Tyma. Упоминаний на хабре не нашел, да будет перевод!

Итак, у вас есть отличная идея.

За годы работы я запустил небольшую кучку проектов и создал несколько компаний. Например Mailinator, Preemptive Solutions, Inc., и Classhat. На самом деле я наделал их гораздо, гораздо больше, но про большинство слышала разве что моя бабушка. Всё потому, что преимущественно это были глупые идеи, неудачные попытки что то сделать, или чересчур масштабные начинания, чтобы я мог довести их до релиза. Поучившись на своих ошибках, я теперь каждую новую идею проверяю на соответствие определённому набору правил, чтобы отсеять хорошие идеи от плохих. Ну или тех, которые мне кажутся таковыми.
Не забывайте, эти правила для канонічного стартапа — когда из сотрудников только вы и ваш друг, а денег — на пиво и чипсы. Если у вас в загашнике завалялись лишние пару миллионов — вы можете творить магию и без этих советов.

JavaScript встречает разработчиков асинхронностью можно сказать чуть ли не с порога. Начинается все с DOM-событий, ajax, таймерами и библиотечными методами, связанными с анимацией (например jQuery-методы fadeIn/fadeOut, slideUp/slideDown). В целом, это все не очень сложно и разобраться с асинхронностью на этом этапе не представляет проблем. Однако, как только мы переходим к написанию более или менее сложных приложений, в которых комбинируется все вышеуказанное, асинхронный поток может сильно затруднить понимание происходящего в коде. Цепочки асинхронных действий, например, анимация > ajax-запрос > инициализация -> анимация, создают достаточно сложную архитектуру, которая не подчиняется строгому направлению «снизу верх». В этой статье я намерен рассказать про свой опыт преодоления трудностей связанных с асинхронным JS.