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

Если коротко – она о том, как рассказывать истории. Точнее даже так: как в работающем бизнесе (или другом проекте) выбрать самые интересные истории, правильно их подать, в полной мере собрать факты и не облажаться потом. Методология построена именно на «не облажаться потом», то есть на проверке фактов и очень спокойной работе без истерических криков. Это продаёт, и этот канал рассказов о своих проектах называется контент-маркетингом (термин появился позже, чем тот же Фёдор из Сыктывкара начал рассказывать про свой книжный бизнес, но раньше, чем он начал печь пиццу). Ещё Евгений Чичваркин с Евросетью живо чувствовал, что нужно что-то такое – но он хотел снимать шоу про работу магазина, чтобы с отжимом поставщиков, собеседованиями, злыми клиентами, инвентаризациями и другими взлётами и падениями.

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

В человеческой культуре есть один удивительный парадокс. Еще 300 лет назад был изобретен потрясающий по эффективности способ познания реальности под названием «Научный метод». Его достижения сегодня мы видим повсюду – в виде огромного развития науки и техники. И в чем тут парадокс, спросите вы? А парадокс заключается в том, что этот метод, дающий столь масштабные результаты, большей частью людей практически не используется!

Это действительно странно, но это факт. Уже черт знает сколько лет изобретенный способ максимально эффективного взаимодействия с реальностью (и проверенный миллионами экспериментов) – даже учеными, как правило, используется не всегда. Выходя из научной лаборатории, ученые забывают о научном методе. Про всех остальных и говорить нечего.

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

  Представьте, что перед вами поставили задачу по реализации навигации внутри помещений. Соответственно, GPS/Глонасс и тому подобные системы спутниковой навигации вам недоступны. Что делать? В этой статье мы с вами подробно рассмотрим варианты решения подобных задач в теоретической части, а в практической – реализуем «в железе» indoor-трекер для работы с маячками iBeacon по Bluetooth BLE на NodeJS на базе новейшей платформы Intel Edison, рассмотрим применение трилатерации и фильтра Калмана, библиотеку CylonJS по работе с датчиками на NodeJS.

Иллюстрация @alvaro_sanchez

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

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

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

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!



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

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

В мире Elixir, Plug представляет собой спецификацию, позволяющую различным фреймворкам общаться с различными web-серверами, работающими в Erlang VM.
Если вы знакомы с Ruby, то можете провести аналогию с Rack: Plug пытается решать те же проблемы, но только другим способом. Понимание основ работы Plug позволит лучше разобраться как с работой Phoenix, так и других web-фреймворков, созданных на языке Elixir.

«Почему ж всё так плохо?» — каждый раз я задаюсь этим вопросом, когда приходится иметь дело с очередным кодом, продуктом или API, созданными для внутренних нужд в непрофильной организации.

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

И деньги ничего не решают: ужасный код и ужасные продукты пишут как маленькие бедные ВУЗы, у которых денег хватает только на рабский труд аспирантов, так и крупные и богатые компании, включая IT-компании, включая зарубежные: несколько раз сталкивался с кодом, который писали зарубежные подрядчики и каждый раз от него хотелось рыдать и биться головой об стену.

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

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

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

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

Рано или поздно разработчик всерьез задумывается о фрилансе. В этот момент большинство идут на биржи. Выбор бирж огромен. В СНГ: fl.ru, weblancer и прочие. Но когда доходишь до дела начинаешь понимать в каком все упадке. Единственным местом где водятся более-менее нормальные заказы можно назвать fl.ru и еще одну-две биржы. Но на fl.ru нужен pro аккаунт, ведь оказывается чтобы взять заказ нужно заплатить бирже, и далеко не факт что тебе что-то светит. Поэтому было решено идти на Upwork.

Ксения Каланова, выпускница нашего курса по копирайтингу и маркетолог в MERA, написала колонку для блога Нетологии о том, как заставить текст звучать «по-английски», даже когда до уровня Advanced еще далеко.

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

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

Если бы не опыт работы переводчиком, меня такие просьбы поставили бы в ступор. Ведь мой текст увидят иностранцы — клиенты компании, руководители!



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

1. Введение

Всем привет, меня зовут Владислав, я из России, и я фрилансер-программист. Сейчас на Хабре очень популярная тема — юридические и налоговые вопросы при работе с Upwork, как получать и декларировать плату от зарубежных заказчиков, и так далее.



Я тоже довольно долго изучал эти вопросы. Российское законодательство по этим вопросам сильно зарегулировано, и все эти законы и правила причиняют массу проблем фрилансерам, работающим на зарубежный рынок. В итоге я принял решение перевести свой «бизнес» в другую юрисдикцию. Изучив все возможные варианты, я выбрал такой путь — зарегистрировать фирму ООО в Латвии, и принимать платежи от заказчиков на эту фирму. То есть просто переместить свой бизнес из России в Латвию.

Я уже год работаю в таком формате, я сталкивался с разными проблемами и оценил плюсы и минусы. В итоге я решил, что в сумме я выиграл от такого решения. В комментариях к статьям о фрилансе я периодически читаю вопросы типа «как работать на заказчиков из США», «Как платить налоги на платежи с Upwork-а», и поэтому я решил поделится своим опытом, тем более что подобных статей я еще нигде не видел.

­­ 

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

Галактика Андромеды

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

Итак, после постановки требований описанной в части 1 можно перейти к проектированию системы.

Основная наша задача в проектировании, как это понятно из названия статьи, добиться разделения интерфейсов на Query и Command, чтобы впоследствии разделить бизнес сценарии на те, которые будут читать данные (Query интерфейсы) и на те, которые будут изменять данные (Command интерфейсы). А также обеспечить минимальное время ожидание (latency) на обновление данных, доступных через Query, после того как мы изменили данные через Command.

«Я никогда не был сильным программистом, и это стимулировало меня к созданию новых мощных языков. Сегодня я работаю по двум направлениям: метапрограммирование и программирование „по-детски“, для детей в возрасте 9-14 лет.»
— Алан Кертис Кей.



Похоже, что этот мужик участвовал во всех институтах передовых разработок, связанных с ИТ.

— Работал в легендарном Xerox PARC, Atari, Apple, Disney, HP.
— Предложил концепцию Dynabook (в 1968 году), которая определила концептуальную базу для ноутбука, планшетного компьютера и электронной книги.
— Один из «отцов-основателей» объектно-ориентированного программирования (SmallTalk, 1969).
— Участвовал в создании первого персонального компьютера Xerox Alto (1973).
— Инициатор полезной движухи «Каждому ребенку по ноутбуку».
— в 2001 году, он основал исследовательский Институт Viewpoints, некоммерческую организацию посвящённую детям, обучению и передовым разработкам программного обеспечения.
— В 2006 бросил дерзкий вызов индустрии — заявил о возможности создания операционной системы с графическим интерфейсом из 20.000 строчек кода.

«Смена точки зрения дает +80 к IQ»
(A change in perspective is worth 80 IQ points)

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

«A change in perspective is worth 80 IQ points»
— Alan Kay

Алан Кей — крутой мужик, мы его на Хабре поздравляли с днюхой.

Напомню заслуги Алана.

• Работал в легендарном Xerox PARC, Atari, Apple, Disney, HP.
• Предложил концепцию Dynabook (в 1968 году), которая определила концептуальную базу для ноутбука, планшетного компьютера и электронной книги.
• Один из «отцов-основателей» объектно-ориентированного программирования (SmallTalk, 1969).
• Участвовал в создании первого персонального компьютера Xerox Alto (1973).
• Инициатор полезной движухи «Каждому ребенку по ноутбуку».
• в 2001 году, он основал исследовательский Институт Viewpoints, некоммерческую организацию посвящённую детям, обучению и передовым разработкам программного обеспечения.
• В 2006 бросил дерзкий вызов индустрии — заявил о возможности создания операционной системы с графическим интерфейсом из 20.000 строчек кода.
• В 2016 присоединился к Y Combinator.

Решили мы перевести его самую концептуальную статью и тут бац, оказывается, что в оригинальной статье нет куска текста. Написали мы в Viewpoints Research Institute, мол, опечатка у вас. Ответила нам Kim Rose, все объяснила, исправила и благославила.

«К счастью или несчастью я научился хорошо читать в три года. Поэтому я успел прочитать около 150 книг до первого класса. Я всегда знал, когда учителя несли чушь.» — Алан Кей



Всем привет.
Раздобыл я, значит, е-мэйл Алана Кея. И задумал я задумку, пообщаться с этим легендарным пионером ИТ. Ну а чтоб накрутить важности и значимости, предложил я Алану Кею интервью от лица всего ИТ-сообщества российского. Он согласился. (И теперь Алан Кей знает, что Хабр — это круто!)


У меня была пара недель чтобы дотянуться до самых «передовых» ИТ-людей рунета. Это оказался довольно веселый и интересный квест. И своеобразный тест на свой/чужой, на знание истории ИТ, на адекватность, на связность ИТ-сообщества, на способность коммуницировать (у меня минус три френда в фейсбуке), на способность организаций/сообществ выступить как единое целое. Огромное спасибо тем, кто этот «тест» прошел.

Набралось 61 вопрос. Алан ответил не на все, но нумерация осталась оригинальной, для удобства синхронизаций версий.

За перевод особое спасибо Данилу Корневу, Александру Козлову и Сергею Даньшину. Если у вас есть рекомендации, как перевести какой-то смысловой блок лучше — пишите в личку.

Негибкий “Энтерпрайз” и гибкие методологии

Существует устоявшееся мнение, что IT-специалист в крупных компаниях — это маленький “винтик” в огромном механизме, призванный выполнять какую-то конкретную функцию. А механизм, в свою очередь, беспощадно эксплуатирует ресурс своих “винтиков”.

Однако мы (в Альфа-Банке в целом и в Альфа-Лаборатории в частности) придерживаемся иного подхода. Подхода, когда усилия всех участников процесса направлены на создание ценности для клиента, при этом путь, которым они этого достигают, может содержать очень много степеней свободы.



Я расскажу, как у нас в Лаборатории выстраиваются процессы работы. Мы опираемся на концепцию Agile. В качестве основного фреймворка мы выбрали Scrum, модель производства — командно-центричная.

Обычно в термин «поддержка» вкладывают только один смысл — это реагирование на беды с хостингом, замена битых дисков, настройка веб-серверов и СУБД, общее повседневное администрирование. Но, на самом деле, это только первый уровень контроля стабильности работы любого интернет-проекта.