Предисловие

В прошлом году решил для себя вплотную познакомиться c Python, а в последствии перебраться на него с PHP. На данный момент моя стезя — веб-разработка, а потому осваивать новый язык я начал именно со стороны веба, в частности, с обзора доступных фреймворков и проектов на них. Познакомившись с возможностями TurboGears, web2py, Django, я всё таки поддался «тренду» и погрузился в мир Django.

На протяжении почти года я честно пытался подружиться с ним. Написал несколько простеньких проектов, но монструозность фреймворка отпугивала, обилие «батареек» путало выбор, а с некоторыми ограничениями не хотелось мириться. Душа требовала лаконичности и однозначности, что в конечном счете привело меня к знакомству с Flask. Изучив документацию по фреймворку и смежным проектам (Jinja2, Werkzeug), я проникся идеологией и стал вплотную изучать фреймворк.

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

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

От переводчика:
Уже опубликовано много материалов по MVC и его производным паттернам, но каждый понимает их по-своему. На этой почве возникают разногласия и холивары. Даже опытные разработчики спорят о том, в чем отличие между MVP, MVVM и Presentation Model и что должен делать тот или иной компонент в каждом паттерне. Ситуация усугубляется еще и тем, что многие не знают истинную роль контроллера в классическом варианте MVC. Предлагаю вашему вниманию перевод хорошей обзорной статьи, которая многое проясняет и расставляет всё по своим местам.

­­ 

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

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

Фреймворк Django, пожалуй, самый популярный для языка Python. Однако, при всей его популярности, часто критикуют его ORM — а именно lookup синтаксис через подчеркивания. На самом деле, такой выбор синтаксиса вполне обоснован — он легок в понимании, расширяем, а главное — прост, как швабра. Тем не менее, хочется красоты, или даже прямо изящества. Но красота — понятие относительное, поэтому будем отталкиваться из конкретных задач. Если заинтриговал — добро пожаловать под кат.

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

functools (это такая свалка для всяких ненужных мне вещей :-).
— Гвидо ван Россум

Может показаться, что статья о ФП, но я не собираюсь обсуждать парадигму. Речь пойдет о переиспользовании и упрощении кода — я попытаюсь доказать, что вы пишете слишком много кода, поэтому он сложный и тяжело тестируется, но самое главное: его долго читать и менять.

В статье заимствуются примеры и/или концепции из библиотеки funcy. Во-первых, она клевая, во-вторых, вы сразу же сможете начать ее использовать. И да, нам понадобится ФП.

blog.miguelgrinberg.com

Miguel Grinberg

---

>>> следующая глава >>>

Эта статья является переводом нового издания учебника Мигеля Гринберга. Прежний перевод давно утратил свою актуальность.

Автор планирует завершить его выпуск в мае 2018. Я, со своей стороны, постараюсь не отставать с переводом.

Попытки найти работу в Японии я начал предпринимать достаточно давно, преследуя две цели: одна — попробовать поработать за границей, а вторая — работать в команде с профессионалами в различных областях IT. Первые попытки закончились без намёка на успех. Практически везде нужно было знание японского языка хотя бы на среднем уровне. А в тех редких случаях, когда этого не требовалось, мне, по каким-то причинам, не удавалось достучаться до HR этих компаний. Тогда я забросил эту мысль, но, в то же время, создал профиль на LinkedIn и старался поддерживать профиль в актуальном состоянии. Спустя несколько лет ситуация изменилась.

Поиск работы

В моем случае LinkedIn оказался единственным инструментом, с помощью которого я мог добраться хотя бы до интервью. В тот момент, когда я вернулся к поискам (начало 2015-го), на сайте уже было достаточно много IT-вакансий в Токио без требований к знанию японского. Как выяснилось позже — это был новый тренд по привлечению специалистов из-за границы.

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

Собеседование

Пригласили на собеседование по скайпу. Всего их было 4 или 5 и только одно из них техническое. На остальных же мне казалось, что интервьюер именно я. Мне рассказывали о компании, проектах, работе, а я задавал вопросы. В итоге за время этих интервью (которые заняли около 2-х месяцев) я познакомился с кем-то из HR, своим будущим менеджером, почти всеми членами команды и с менеджером L2 (один из executive). Т.е. ещё даже не зная наймут ли меня, я уже знал всех тех, с кем мне предстоит работать. Мне это показалось чем-то невероятным.

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


Каждый предмет в Skyrim (в том числе эта бесполезная чаша рядом со ступеньками) находится в одинаковом месте для всех игроков.

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

⬝ 11 библиотек (наборов компонентов) для Angular, о которых стоит знать в 2018-м
⬝ 11 библиотек (наборов компонентов) для Vue, о которых стоит знать в 2018-м
⬝ 11 библиотек (наборов компонентов) для React, о которых стоит знать в 2018-м

Современные фреймворки для разработки веб-приложений сформировали вокруг себя сообщества, члены которых, помимо прочих дел, занимаются разработкой библиотек для этих фреймворков. Подобные библиотеки находят применение во множестве проектов. Как правило, можно даже говорить о том, что, например, на чистом React, Angular или Vue, без применения дополнительных средств, веб-приложения сегодня не разрабатывают.



Представляем вашему вниманию перевод первого материала из серии статей, в каждой из которых рассмотрены 11 наиболее интересных библиотек для разных веб-фреймворков, на которые стоит обратить внимание в 2018-м. Сегодня поговорим о библиотеках для React.

В октябре 1994 года я только начал свою карьеру добросовестного программиста видеоигр в небольшом стартапе SingleTrac, который позже получил славу и почёт (но, к сожалению, не очень много удачи) благодаря таким сериям игр, как Warhawk, Twisted Metal и Jet Moto. Но в то время в компании было меньше 20 сотрудников, и официально она работала всего около месяца. Это случилось в мою первую рабочую неделю, возможно, в первый или второй день. Из кабинета разработчиков слышались восторженные крики.

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

Немного лирики

В те давние времена, когда трава была зеленее и деревья были выше, я твёрдо верил, что такие страшные слова, как дивергенция потоков, cache missing, coalescing global memory accesses и прочие не позволяют эффективно реализовать задачу множественного поиска на GPU. Годы шли, уверенность не исчезала, но в один прекрасный момент я наткнулся на библиотеку PFAC. Если интересно, на что она способна — добро пожаловать под кат.

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

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

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

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

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

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

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

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

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

Если вы программист, то, возможно, у вас возникали ситуации, когда в выбранном игровом движке или библиотеке нет нужной функции. За этим следовал ужасающий момент, когда вам приходилось обыскивать весь Интернет в поисках кода, написанного людьми, решавшими эту проблему до вас (я говорю о вас, пользователи StackOverflow). Конечно, в этом нет ничего плохого (я и сам так поступаю), но очень часто вы можете сделать это самостоятельно, даже когда речь идёт о таких теоретических задачах, как геометрия или перетасовка. Я один из тех людей, которые всегда пытаются понять, как всё работает, и разве есть способ понимания лучше, чем прийти к нему самому, заново изобретя решение на лету (если, конечно, оно существует)?

Ставим перед собой пример задачи

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

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

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

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

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

Статья будет полезна тем, кто хочет:

— в общих чертах понять, что такое авторское право (но лучше обратиться к юристу);
— подобрать свободную лицензию для своего проекта;
— разобраться, что нужно писать в шапке файла исходного кода.

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.

Ого! Как много информации.