С недавних пор я снова перешёл на 100% работу из дома и стал использовать стол для работы стоя. Хочу поделиться дампом своего опыта на тему здоровья, призвать закончить прокрастинировать и начать работать стоя.

Сначала, о том, почему стол для работы стоя — не панацея...

Салют, хабровчане! В преддверии запуска нового потока по курсу «Web-разработчик на Python» хотим поделиться новым полезным переводом. Поехали!



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

def f(x, l=[]):
    for i in range(x):
        l.append(i * i)
    return l
>>> f(2)
>>> f(3, [0, 1, 2])
>>> f(3)

Вопрос: Что выведет этот код?

В моём прошлом посте про поступление в магистратуру без бакалавриата читатели очень интересовались как перебраться в Европу без диплома.

Итак, мне 26 лет, я веб-разработчик в Берлине и я никогда не учился в университете.

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

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

Если вам это знакомо, то данная статья как раз для вас, так что продолжайте читать.

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

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

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

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

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

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

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными



Если вы пока не знаете о том, что такое Docker, сейчас у вас есть шанс сделать первый шаг к пониманию этой платформы. А именно, освоив этот материал, вы разберётесь с основами Docker и попутно приготовите пиццу.

Я никогда не смогу ходить! Потому что я ползаю.
—Цитаты великих

    Меня всегда учили прежде всего здороваться, так что — здравствуйте. Сегодня я расскажу про творческие (и не очень) муки, страдания и боль, которые я испытывал на протяжении определенного периода своей жизни, который я обозначу как ПРОЕКТ. Сначала он был на JavaScript (node.js), а теперь он на Scala (Play). Сразу скажу, что я — один из самых субъективных негодяев в обозримой Вселенной, поэтому некоторые обороты, высказывания и иже с ними могут быть восприняты уважаемыми читателями весьма неоднозначно. Короче, я предупредил. И у меня еще одна небольшая просьба — если уж взялись прочитать статью, то не кидайтесь сразу строчить разоблачающие комментарии. Дочитайте. Я не Пастернак, правду говорю. И вообще, почти все спорные моменты так или иначе освещаю, объясняю.

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3

---

Перевод статьи Sashko Stubailo GraphQL vs. REST

---

Два способа отправки данных по протоколу HTTP: в чем разница?

GraphQL часто представляют как революционно новый путь осмысления API. Вместо работы с жестко определенными на сервере конечными точками (endpoints) вы можете с помощью одного запроса получить именно те данные, которые вам нужны. И да — GraphQL гибок при внедрении в организации, он делает совместную работу команд frontend- и backend-разработки гладкой, как никогда раньше. Однако на практике обе эти технологии подразумевают отправку HTTP-запроса и получение какого-то результата, и внутри GraphQL встроено множество элементов из модели REST.

Так в чем же на самом деле разница на техническом уровне? В чем сходства и различия между этими двумя парадигмами API? К концу статьи я покажу вам, что GraphQL и REST отличаются не так уж сильно, но у GraphQL есть небольшие отличия, которые существенно меняют процесс построения и использования API разработчиками.

Так что давайте сразу к делу. Мы определим некоторые свойства API, а затем обсудим, как они реализованы в GraphQL и REST.

SSH/HTTPS/OpenVPN/Telegram и всё на одном порту?! Что?!
— Да!

• Хотите скрыть наличее у вас некоторых сервисов?
• В публичной wi-fi сети блокируется всё кроме 443 (https) порта?
• Настроили Telegram Proxy/OpenVPN и не хотите его «светить» ?
• SSH подключение к своему серверу из стран с цензурой?

На все эти вопросы ответ один — Мультиплексирование SSL/TLS соединений, или SSLH.

В посте мы рассмотрим как в 1 команду спрятать кучу сервисов за 1 портом.

Глеб Летушов, редактор-фрилансер, адаптировал для блога Нетологии чеклист с Github от David Dias. Этот чеклист уже переводили, но так как на Хабре его нет, мы решили, что он пригодится. В чеклисте собран полный список элементов, которые необходимо проверить перед запуском и публикацией сайта.



Список основан на многолетнем опыте фронтенд-разработчиков, а дополнения собраны из общедоступных источников.

С момента появления Node.js диагностика совершенствовалась в несколько этапов, от отладки приложений до глубокого анализа производительности. В этот раз речь пойдет о стратегиях использования таких инструментов, как core dump debuggers, flame graphs, ошибках в production и утечке памяти.


Мы расшифровали для Хабра доклад Николая Матвиенко из Grid Dynamics с нашей конференции HolyJS. Далее повествование идёт от лица спикера.

UPDATE 2018-02-04: Еще одна мудрость со временем накипела: если хочется полной свободы выбора компаний любого размера, то лучше сразу говорить, что вы нашли хорошую компанию по релокейту и всё, что требуется, это финансовая поддержка. Деньги тут есть (особенно у страртапов), а времени — нет.

UPDATE 2017-03-19: По опыту двоих приятелей из Берлина (из России и Коста-Рики) могу обнадёжить, голубую карту могут сначала не дать, а через полгода таки дать прямо в Германии. Немцы тоже люди и их чиновники тоже умеют и искренне заблуждаться, и нарочно упираться.

UPDATE 2017-01-08: год спустя поимел опыт поиска и найма фронтендеров для двух компаний. Заявляю, что хорошего кандидата, подписавшего договор, готовы ждать месяц-два. Меня один средних размеров стартап согласился ждать 4 месяца после очного интервью. Так что заехать себя показать, а потом начать удаленно и через пару месяцев перебраться — вообще шоколад.

UPDATE 2016-09-02: полгода спустя немного подросла нижняя планка з/п для голубой карты, а остальное пока в силе.

UPDATE: по просьбе chilicoder добавляю ремарку: «автор смог переехать и найти работу даже без признанного диплома».

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

WebRTC, технология голосовых и видеозвонков в браузерах (а еще realtime передачи произвольных данных, peer-to-peer пробивания NAT и захвата экрана) никогда не была простой. Долгая история, несовместимости между браузерами, запутанная документация, множество решаемых задач и используемых протоколов. Возможность позвонить и принять звонок из браузера всегда была одной из ключевых «фишек» нашей платформы Voximplant, и так как мы в этом неплохо разбираемся, то стараемся следить за интересными статьями и адаптировать их для аудитории Хабра. Под катом перевод свежей статьи от ребят из callstats.io — сервиса сбора статистики по качеству звонков для браузера. В небольшой статье они рассказывают о протоколе RTP с помощью которого, собственно, браузер и передает пакеты с голосом или видео.

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


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

«Начало — более чем половина всего».

Это очень древний GTD-принцип: возраст его, вероятно, исчисляется тысячелетиями. (Например, Викицитатник в настоящее время приписывает его Аристотелю, хотя и без подтверждающего указания на первоисточник.) Суть его в том, что с чистого листа начинать какой-либо проект бывает очень трудно (и даже приходится заставлять себя); а вот если есть несколько простых начальных шагов, выполнение которых приводит к появлению частично готового проекта, то продолжить работу над ним «по инерции» становится куда проще — так просто, как если бы проект этот ужé был не только начат, но и готов даже более, чем наполовину. А кроме того, когда заранее хорошо знаешь, какими должны быть начальные шаги, то тогда трудно бывает допустить ошибку, совершая их.

Мне довелось сочинить более десятка модулей для Node.js с открытым исходным кодом и опубликовать их в качестве пакетов npm. Чем больше модулей я делал, тем сильнее понимал (в том числе путём проб и ошибок), что начальные шаги для их создания могут быть одинаковыми и даже могут совершаться в одном и том же порядке. Сегодня я публикую этот порядок в надежде на то, что он станет подспорьем в работе программистов, сочиняющих свой код на языке JavaScript для движка Node.

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

Однажды я отправился на поиск учебных руководств по аутентификации в Node.js/Express.js, но, к сожалению, не смог найти ни одного, которое меня бы полностью устроило. Некоторые были неполными, некоторые содержали ошибки в сфере безопасности, вполне способные навредить неопытным разработчикам.

Сразу скажу, что я всё ещё нахожусь в поиске надёжного, всеобъемлющего решения для аутентификации в Node/Express, которое способно составить конкуренцию Devise для Rails. Однако, удручающая ситуация в сфере руководств подвигла меня на подготовку этого материала. Тут я разберу некоторые наиболее распространённые ошибки в области аутентификации и расскажу о том, как их избежать.

Введение

Хорошо известна возможность интеграции Python и C / C++. Как правило, этот прием используется для ускорения программ на Python или с целью подстройки программ на C / C++. Я хотел бы осветить возможность использование python для тестирования кода на C/C++ в IDE без поддержки системы организации тестов в IDE. С моей точки зрения это целесообразно применять в сфере разработки программного обеспечения для микроконтроллеров.

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

При разработке программ для микроконтроллеров, я сталкивался с отсутствием стандартного ввода / вывода (конечно можно переопределить функции ввода вывода и в симуляторе, выводить данные через UART — но часто UART уже задействован, да и симулятор работает не всегда корректно) и большими рисками вывести из строя аппаратное обеспечение ошибочной бизнес логикой. На стадии разработки, я реализовывал отдельные проекты, тестирующие части программы и далее на меня ложилась ответственность за запуск всех тестовых приложений после внесения изменений. Конечно, это все можно автоматизировать. Так можно работать, но я нашел способ лучше.

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

Начнём с того, что компьютеры под управлением ОС Windows склонны со временем терять память. Ну, по крайней мере, у меня, при моём способе ими пользоваться. После пары недель без перезагрузок (или, например, всего одного уикэнда за который я 300 раз пересобрал Хром) я стал замечать, что диспетчер задач начинает показывать мне очень маленькое количество свободной оперативной памяти, но в то же время в системе нет никаких процессов, которые эту самую память активно используют. В том примере выше (с 300 сборками Хрома) диспетчер задач сказал мне, что в системе занято 49.8 ГБ плюс ещё 4.4 ГБ памяти сжато — но при этом запущено всего несколько процессов, и все они в сумме даже и близко не используют столько памяти:



В моём компьютере 96 ГБ оперативной памяти (да, я счастливчик) и когда у меня нет вообще никаких запущенных процессов — я, знаете ли, хотел бы видеть ну хотя бы половину этой памяти свободной. Я правда рассчитываю на это. Но иногда этого достичь не удаётся и мне приходится перезагружать ОС. Ядро Windows написано качественно и надёжно (без шуток), так что память не должна бы пропадать бесследно. Но всё же она пропадает.

Рассказывать айтишникам про психологию то еще дело, некоторые читатели скажут: «Bullshit!», и вообще не поверят, потому что психологию, даже прикладную, нельзя назвать точной наукой. Тем не менее, задача этой статьи — показать и доказать вам, что некоторые модели действительно работают. В основе доклад Сергея Котырева из UMI на РИТ++ 2017, от его лица дальше и пойдет повествование.



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

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

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