2 года назад я написал статью о классификации знаний в области программирования. Это было на волне интереса и моей активной деятельности по самообразованию в компьютерных науках. Написал статью и забыл о ней. Публиковать на Хабре не собирался. В конце концов, она базируется на моем личном опыте и знаних, которые могут оказаться весьма субъективны.

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

Но прежде, чем «запустить» материал, еще небольшое отступление. О том, почему вообще я все это писал. Дело в том, что у нас в странах бывшего СССР с образованием в области IT очень туго. С одной стороны нет программ обучения, которые подготовят специалистов на должном уровне (наверное, за очень редкими исключениями, которые можно отнести к погрешности). С другой стороны, из-за широких возможностей самообразования, программисты и не спешат учиться в ВУЗах — все стремятся начать практиковать как можно раньше. Часто изучается только одно направление (например PHP+Mysql — самое популярное) и в бой. Причем, на этом все заканчивается. В итоге у нас огромное количество программистов, которые и базовых вещей не знают. Отсюда вытекают проблемы с качеством кода, и с эффекивностью алгоритмов, с велосипедированием.

Но программирование — это полноценная область знаний, которая требует в том числе и инженерной подготовки. Точно так же, как строительство или телекоммуникации. Да, построить дом (особняк) можно своими руками и без образования. А поднять большинство сайтов можно прочитав пару книг по PHP и HTML. Но многоэтажку без специальной подготовки не построишь, как и Гугл не напишешь, не зная основ.

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

Поехали.

Итак, вы решили внедрить двухфакторную авторизацию для своего проекта, и решили не следовать примеру Яндекса и изобретать свой новый стандарт, а воспользоваться существующим, а именно TOTP по rfc6238
Алгоритмы генерации и валидации одноразовых кодов достаточно подробно описаны как в самом RFC, так и многочисленных имплементациях для всех языков и платформ.

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

В этом случае наиболее распространенным выходом из положения является использование «чужого» приложения (например того же Google Authenticator-а), но в этом случае решение будет не полностью свое (вот на что намекает звездочка в заголовке).

А хотите двухфакторную авторизацию полностью свою и за минимум вложений? Тогда вам под кат

Несмотря на то, что Go считается одним из самых легких для входа языков, приходится регулярно слышать: «как-то все непонятно, какие-то переменные GOROOT и GOPATH нужно устанавливать». И хотя тема полностью раскрыта на официальном сайте Go, не будет лишним объяснить совсем простым языком.

TL;DR


Теперь чуть подробнее:

Простой диспетчер задач с веб-интерфейсом, написанный на языке GO для Unix-систем включая Android.

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

Мне довелось поработать (fb) в интернет издании Лента.ру. Пройти путь от разработчика до технического директора. Успешно реализовать полноценный перезапуск. Попутно занимаясь подобными проектами меньшего масштаба. Теперь мы с командой занимаемся подготовкой перезапуска интернет газеты Ведомости (fb).

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

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


OpenIAB разрабатывается исходя из следующий принципов:

* API библиотеки должно быть максимально похоже на API Google Play In-app Billing.
* Один APK файл должен работать для всех поддерживаемых магазинов приложений.
* Никаких посредников при проведении оплат. Это значит что нет никаких третьих сторон которые обрабатывают транзакции. Под капотом библиотеки все транзакции обрабатываются все теми же Google Play, Yandex.Store и другими нативными приложениями магазинов. По сути, OpenIAB является прослойкой, приводящей API различных аппсторов к одному API, который мы и будем использовать в своем приложении.

Введение

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

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

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

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

Я давеча написал комментарий о том, что компании Майкрософт давно пора перестать издеваться над веб-разработчиками и перейти на движок Gecko. Многие, видимо, посчитали это неуместной шуткой; тем не менее, это таки вовсе не шутка, а констатация факта. Те, кто с этим не согласен, видимо не пытались ещё разрабатывать под этот замечательный браузер.

Давайте я расскажу вам, какой это замечательный процесс.

Примечание от переводчика:

Я решил перевести эту статью в основном из-за личности автора. TJ вложил очень много усилий в развитие Node.js и его инфраструктуры, он автор таких проектов как express, jade, mocha, stylus, автор 550 репозиториев на npm. Существуют также теория, что под этим именем скрывается группа людей.

Как бы то ни было, JavaScript и Go сообщества в ближайшие время ожидают изменения.

Покидая страну Node.js

Я сражался с Node.js достаточно долго, что бы перестать получать от этого удовольствие, это мое официальное прощание! И, что еще важнее, я ищу людей, которые смогут поддерживать мои проекты!

Node отлично справляется с некоторыми вещами, но, к сожалению, это не самый подходящий инструмент для того, что мне сейчас интересно. Я все еще планирую использовать его для сайтов, но если вы хотели бы заняться поддержкой одного из моих проектов, дайте мне знать. Просто оставьте комментарий с вашим именем на Github, ссылкой на npm и названием проекта. Как обычно я прошу не делать больших изменений в существующих API: создать новый проект будет проще.

Я также продолжу поддерживать Koa.

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

Новости

• Вышел Go 1.3 — Версия 1.3 была выпущена 18 июня, спустя шесть месяцев после версии 1.2, и она не содержит изменений в языке. Основная работа была произведена над реализацией, что обеспечило точную сборку мусора, рефакторинг тулчейна, результатом которого стала более быстрая сборка, особенно больших проектов, и значительное улучшение производительности. Прочитать о новом релизе подробнее можно здесь [ru], и еще подробнее — на официальном сайте [en] и в коротком обзоре [en].
• Поддержка Android в Go 1.4 [en] — Скорее всего, в новой версии языка появится поддержка Android, причем биндинги для OpenGL и Java позволят писать игры на Go и использовать свой код на мобильной платформе.
• Dropbox отдали в open source свои библиотеки для Go [en] — Как стало известно, хотя в Dropbox и продолжают разрабатывать большую часть функционала на Python, но критические для производительности компоненты уже мигрировали на Go. В связи с чем компания написала несколько своих «велосипедов», которые многим будут полезны. Выложенные компоненты предназначены для работы с кэшированием и Memcache, построением SQL-запросов, улучшенным выводом ошибок и улучшенным алгоритмом хэширования.
• Состоялась встреча Golang Moscow — Видеозаписи докладов с московской встречи гоферов, состоявшейся 21 июня, можно посмотреть по ссылке.
• На прошедшей Google I/O 2014 было несколько докладов про Golang — И их записи будут доступны в виде скринкастов несколько позже.
• Cayley, открытая графовая база данных от Google, написанная на Go — Работает как надстройка над LevelDB или MongoDB. Есть обзор и видео.
• juju — Крутой DevOps-инструмент для управления облаками от Ubuntu — теперь и на Github.
• Релиз beego 1.3 — Новый релиз фреймворка для быстрой разработки веб-приложений и API на Go
• Релиз отличного менеджера зависимостей gpm v1.2.3

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

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

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

Автор: maxim_korobtsev, WorkAndPlay.Ru

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

Фиксить баги скучно, если не превращать это в игру. Особенно, если речь идет о низкоприоритетных багах, которые не были исправлены в свое время из-за незначительности. Но, обо всем по порядку!

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

Все началось за несколько месяцев до Багатлона, когда мы, Work&Play, вместе с OK придумывали игровые механики и само соревнование. Родилась достаточно неплохая идея: расфасовать все множество накопившихся низкоприоритетных багов по группам (коробкам с багами). Для каждого бага заранее указать навыки, которые он прокачивает у того, кто его фиксит или проверяет. Далее раз в несколько месяцев устраивать соревнование. Причем, победителем будет не тот, кто больше пофиксил, а тот, кто больше всех прокачался пока багфиксил. Также хотелось, чтобы вся игра проходила без отрыва от работы(в рабочие дни), по тикетам из багтрекера и доступ к ней был прямо из Jira.

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

Что у нас получилось в итоге?

В результате, после нескольких месяцев работы над плагином, у нас получилось вот это:

JavaScript принято считать прототип-ориентированным языком программирования. Но, как ни странно, этим подходом практически никто не пользуется: большинство популярных JS-фреймворков явно или неявно оперируют классами.
В этой статье я хочу рассказать об альтернативном способе программирования на JavaScript, без использования классов и конструкторов — чистым прототипным ООП и особенностях его реализации на ECMA Script 5.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

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

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.