От переводчика: публикуем для вас статью Даррена Барнса, который делится своим опытом работы с GitHub. Его советы будут полезны, в первую очередь, новичкам. Возможно, и опытный кодер найдет что-то для себя.

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

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

19-20 декабря в Лондоне состоялся третий международный конгресс по отношениям с секс-роботами (Third International Congress of Love and Sex with Robots). Изучив основные темы докладов, журналист Engadget Даниэль Купер пришел к выводу, что телевидение и кинематограф уже осветили большинство из тех проблем, что сейчас обсуждают ученые.

Поэтому если вы хотите понять ключевые вопросы этики (секс)-роботов, у вас есть два пути. Первый — на несколько лет зарыться в скучные книжки. Второй — сесть перед ТВ-экраном. В «Футураме», «Мире Дикого Запада» и «Степфордских женах» Купер нашел отражения тех проблем, над которыми спорили участники конгресса.

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

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



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

Возможно. Но часто проект бывает с самого начала обречен на провал из-за недопонимания одного важного момента.

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

Это предположение — неверно.

Проект — это не лист бумаги, не двумерный объект — у него есть глубина.

Каждую функцию на поверхности можно раскрыть — и так слой за слоем. Будь у меня склонность к громким заголовкам, я бы сказал, что всякое приложение — это лук, и нужно уметь правильно его чистить. Не очень понятно? Тогда давайте я поясню, что имеется в виду, и расскажу, почему не получается раскрывать слои приложения без слёз.

Переведено в Alconost

7 команд и ни одного менеджера – думаете, такое возможно? Мы построили процесс, в котором показываем на каждом демо по 1-2 фичи от команды, проводим ретро команд, ретро релизов и при этом получаем реальное удовольствие от работы. Хотите организовать свою работу так же? Тогда добро пожаловать под кат.



Мы, компания Renga Software, занимаемся разработкой программных продуктов для проектирования зданий и сооружений в соответствии с технологией информационного моделирования (BIM). Идем спринтами, выпускаем релизы каждые 3-4 месяца. Пользователей системы с каждой неделей становится всё больше. Продукт совсем молодой, поэтому бэклог переполнен важными, а главное, интересными задачами. Но как в короткие сроки разработать продукт, который будет использоваться для проектирования жилых домов, детских садов, больниц и театров?

Я только что закончил семь собеседований в компаниях Кремниевой долины. В конечном итоге я принял предложение разработки программного обеспечения в Facebook.

Вот как я готовился к этим собеседованию и чему я научился на этом пути.

Мой многолетний путь в Кремниевую долину

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

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

Я оставил свое место в качестве ведущего инженера iOS в чудесной компании в Мельбурне и я вернулся обратно в мой родной город Перт, чтобы учиться. Тут я буду готовиться к переговорному процессу которое ждет меня в Кремниевой долине. Я знал, что это будет невероятно сложно и тяжело.

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

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

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

---

Выбор между различными паттернами разработки, всегда сопровождается рядом споров и дискуссий, а разные взгляды разработчиков на это еще больше усложняют задачу. Существует ли решение этой идеологической проблемы? Давайте поговорим о MVC, MVP, MVVM и MVI прагматично. Давайте ответим на вопросы: “Почему?”, “Как найти консенсус?”

Программист Terra Nova: Strike Force Centauri, System Shock 2 и серии Thief Шон Барретт рассказывает о том, что привело его к программированию трёхмерной графики и работе над играми.

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

Когда я был подростком, в 80-х у меня был компьютер Atari 800, на котором я занимался обычными вещами (немного игр, в основном BASIC). (Технически, по крайней мере, изначально, им владела моя семья, но я был единственным пользователем.) Хотя это было практически невозможно на 800, но я заинтересовался 3D-графикой. Я изучал Pascal и работу 3D одновременно с расшифровкой программы для рисования каркасной графики из журнала Byte; я предпринимал хакерские попытки воспроизвести тот же эффект на 800. (В конце концов мне удалось выполнить на 800 трассировку лучами простой сферы с освещением по Ламберту, а затем клетчатых и отражающих сфер на Atari ST моего друга.)

«Мастер совершает больше ошибок, чем новичок — попыток»

Предлагаем 8 вариантов проектов, которые можно сделать «по фану», дабы получить реальный опыт разработки.

Проект 1. Клон Trello

Клон Trello от Indrek Lasn .

Что вы освоите:

• Организация маршрутов обработки запросов (Routing).
• Drag and drop.
• Как создавать новые объекты (доски, списки, карточки).
• Обработка и проверка входных данных.
• Со стороны клиента: как использовать локальное хранилище, как сохранять данные в локальном хранилище, как читать данные из локального хранилища.
• Со стороны сервера: как использовать базы данных, как сохранять данных в базе, как читать данные из базы.

Тут пример репозитория, сделанного на React+Redux.

Захват Золотого Кольца-0

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

Модуль ядра Linux — это скомпилированный двоичный код, который вставляется непосредственно в ядро Linux, работая в кольце 0, внутреннем и наименее защищённом кольце выполнения команд в процессоре x86–64. Здесь код исполняется совершенно без всяких проверок, но зато на невероятной скорости и с доступом к любым ресурсам системы.

Не для простых смертных

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

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

Но я хочу поговорить не об обмане извне, а об обмане изнутри. То есть, о самообмане.

А конкретно, о самообмане который возникает при непонимании того, что, как и почему происходит в интернете.

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

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

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

Что за горутины?

Горутина (goroutine) — это функция, выполняющаяся конкурентно с другими горутинами в том же адресном пространстве.

Запустить горутину очень просто:
go normalFunc(args...)

Функция normalFunc(args...) начнет выполняться асинхронно с вызвавшим ее кодом.

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

Сколько вешать в граммах?

Чтобы было проще ориентироваться, рассмотрим цифры полученные опытным путем.

Большинство людей с возрастом постепенно теряют способности мыслить логически, анализировать и решать новые нестандартные задачи, использовать усвоенные знания и навыки. Это физиологический процесс. Исследователи из британской Лаборатории цифрового творчества (DC Labs) Йоркского университета решили выяснить, можно ли затормозить этот регресс с помощью игр, и если можно, то с помощью каких.

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

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

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

Исследователи из Йорка попробовали в своём исследовании ответить на вопрос, может ли конкретная игра стать причиной роста интеллекта. Для изучения вопрос взяли самые массовые игры — MOBA и шутеры.

Дисклеймер: у меня за спиной более десяти лет разработки на PHP. Я начал использовать его, когда PHP4 был совсем малышом, а PHP5 — только мечтой компании Zend. С помощью него я сделал многое, я любил его, проклинал и не без стыда наблюдал за тем, как он растёт и развивается. Я всё ещё использую его в некоторых доставшихся по наследству проектах, но предпочитаю больше его не применять. Также хочу отметить, что я не сотрудничаю с создателями фреймворков или инструментов, упомянутых в статье.

TL;DR (англ. too long; didn't read. Так, в частности, говорят, когда лень читать статью целиком — прим. пер.): если ваш проект основан на функциях фоновых процессов (фоновых служб, демонов — прим. пер.), избегайте PHP.

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

Возьмите переменную и увеличьте её на 1. Звучит просто, верно? Ну… С точки зрения PHP-разработчика, наверное, да. Но так ли это на самом деле? Здесь могут возникнуть некоторые трудности. Существует несколько способов инкрементировать значения, они могут выглядеть равноценными, но под капотом PHP работают по-разному, что может привести к, так сказать, интересным результатам.

В мире PHP-программирования существует набор трендов. Некоторые люди активно продвигают их (в книгах и на сайтах) как «современный PHP», а другие подходы выставляют как устаревшие, глупые или просто неверные.

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

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

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

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

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

Я рассматриваю такую задачу. Есть пул заданий, которые надо побыстрее выполнить. В PHP есть и другие инструменты для решения этой задачи, тут они не упоминаются, статья именно про pthreads.

Стоит отметить, что автор расширения, Joe Watkins, в своих статьях предупреждает, что многопоточность — это всегда не просто и надо быть к этому готовым.

Кто не испугался, идем далее.

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

Код на R для примеров, представленных в этой статье, можно найти здесь в Библии задач машинного обучения. Кроме того, после прочтения этой статьи стоит изучить часть 2, Neural Networks – A Worked Example, в которой приведены подробности создания и программирования нейросети с нуля.

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

Deployer хорош во многих отношениях. Код скрипта для деплоя получается коротким. Написан на старом добром Пыхчанском — то бишь, скорее всего, ставить отдельно какие-то другие инструменты на сервер вам не придётся. Если же и придётся — то PHP обычно устанавливается одной командой на любом сервере. Почему-бы и не заюзать его в своих проектах?