Часто в общении с коллегами по ИТ цеху обсуждается вопрос, на сколько эффективно создавать команды, работающие удаленно. Какого-то единого мнения в обсуждениях никогда нет — кто-то не приемлет выстраивать бизнес в формате Remote (удаленная работа), а кто-то наоборот «за» такой формат. Сегодня я расскажу, как мы организуем работу команды Dental Cloud и сделаю обзор двух книг о дистанционной работе, однозначно доказывающих преимущества Remote — Кали Ресслер и Джоди Томпсон «Офис в стиле фанк» и Remote: Office Not Required. Авторами последней выступили Джейсон Фрид, основатель компании 37signals, и Дэвид Ханссон, автор популярного фреймворка Ruby on Rails.

Предлагаю читателям «Хабрахабра» перевод поста «Rust Once, Run Everywhere» из блога Rust за авторством Alex Crichton. Сам я некоторое время уже интересуюсь этим языком, а в связи со скорым релизом версии 1.0 хотел бы продвигать его по своим скромным возможностям. Ничего своего, к сожалению, сейчас у меня написать не получается, но когда-то я занимался переводами, так что решил вспомнить давнее дело. Перевод этого поста на Хабре я не нашёл, так что решил сделать свой.
Некоторые термины, которые обозначают уникальные для Rust-а концепции (ownership, borrowing, lifetime parameter), я не знал, как лучше перевести на русский, так что постарался подобрать наиболее подходящие по смыслу и более-менее понятные для русскоязычной аудитории слова. Любые предложения-улучшения принимаются.

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

Rust начинался как проект, решающий две трудные проблемы:

• Как обеспечить безопасность (работы с памятью) в системном программировании?
• Как сделать многопоточное программирование безболезненным?

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

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

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

С точки зрения многопоточности это означает, что вы можете пользоваться различными парадигмами (передача сообщений, разделяемое состояние, lock-free-структуры данных, чистое функциональное программирование), и Rust позволит избежать наиболее распространённых подводных камней.

Вот какие особенности у многопоточного программирования в Rust:

Ansible — сравнительно молодая система управления конфигурацией, его история насчитывает чуть более трех лет. Но, несмотря на это, он стремительно и быстро ворвался в мир систем управления конфигурацией, потеснив Chef, Puppet и SaltStack.

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

Итак, чем же хорош ansbile:

• низкий порог входа;
• декларативный язык описания конфигурации;
• на управляемые узлы не нужно устанавливать никакого дополнительного ПО;
• просто написать дополнительный модуль.

Rust — системный язык программирования, который исполняется чертовски быстро, предотвращает почти все падения, а также устраняет неопределённости совместного доступа к данным. Он разрабатывается Mozilla как инструмент для создания обозревателя нового поколения — Servo.

Пункты соприкосновения

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

На днях нам пришло письмо от Роскомнадзора. Там было сказано, что и до нашей компании у них дошли руки.

Совсем недавно в ходе обсуждения поста Опыт поиска работы на бирже Elance разгорелось горячее обсуждение способов конкуренции с индийцами и пакистанцами на площадках сайтов для фрилансеров. В продолжение этой темы публикую свой вольный перевод
статьи Евгения Розинского о проблемах краудсортинга в Индии. По словам Евгения он имеет 15 летний опыт в этой области и знает о чём говорит. Это взгляд из США, со стороны работодателей. Статья была опубликована ещё в 2013 году, но проблемы которые в ней рассматриваются сегодня стали ещё более актуальными.

Индийский ИТ-аутсорсинг стал бизнесом, который поставлен на поток. Бизнесом без каких-либо инноваций Единственным сомнительным плюсом которого является дешевизна. Но не миф ли это?

Это не попытка написать научную статью или предсказать будущее. Это просто личное мнение, сложившиеся у меня на основе более чем 15 лет работы с различными поставшиками услуг в Индии и по всему миру. Не стоит рассматривать статью как попытку сформировать стереотип для каждого сотрудника страны с населением 1,2 миллиарда человек. На протяжении многих лет мне посчастливилось работать с блестящими индийскими инженерами и менеджерами, как в Индии, так и в США. Этой рецензией я пытаюсь описать индустрию аутсорсинга Индии в целом и отметить характерные проблемы с которыми мы сталкиваемся в качестве клиентов, а не людей, работающих там.

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

“Это унылое диалоговое окно действительно нужно?”

В этой статье я изложил главные принципы Material Design и дал советы по их воплощению. Текст написан по следам мастер-класса для разработчиков, который мы, Роботы, устраивали совместно с российским офисом Google (Think Mobile).


Когда-то все продукты Google выглядели по-разному плохо. Даже один продукт на разных платформах выглядел неконсистентно.

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

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

STI (Single Table Inheritance) — паттерн проектирования, который позволяет перенести объектно-ориентированное наследование на таблицу реляционной базы данных. В таблице БД должно присутствовать поле идентифицирующее название класса в иерархии. Зачастую, в том числе в RoR, поле называют type.

Таким образом, мы можем иметь одну таблицу и несколько типов объектов (моделей), которые будут в ней храниться. В случае с вышеупомянутой хабразаметкой — это одна таблица постов, которая хранит посты разных типов: ссылка, подкаст, статья, перевод и т.д.

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

Приступим.

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

Привет, Хабр!

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

• С чего начать обучение программированию?
• У вас есть курс по Java для новичков, но я слышал, что нужно изучать Python, правда ли это?
• На других сайтах все просто и понятно, а у вас какие-то компиляции и тесты!
• Непонятно зачем нужен этот ваш курс по алгоритмам, в реальной жизни все алгоритмы уже реализованы в стандартных библиотеках

Но сложнее всего объяснить новичку, грубо говоря, во что он ввязывается. Благодаря очень простым, игровым образовательным проектам многие считают, что программирование это очень легко, а наши виртуальные машины, где нужно запускать тесты и компилировать код – это надуманная сложность. Давно хотелось найти такой материал, который бы подготовил новичка к длинному и сложному пути к карьере программиста. И недавно наши коллеги из Viking Code School такой материал написали! А мы его перевели для вас.



Квинси Ларсон был просто “офисным парнем в костюме”. Он решил научиться программировать. Начал спрашивать людей вокруг. Изучил немного Руби, потом быстренько посмотрел на другие языки вроде Scala, Clojure и Go. Он изучил Emacs, а потом Vim, а потом раскладку Dvorak. Он втыкал в Линукс, копался с Лиспом и кодил на Питоне, и жил при этом в командной строке больше полутора лет.

Его швыряло туда-сюда как листочек в торнадо. Каждый совет, который он слышал, тащил его то в одну, то в другую сторону, до тех пор пока он не прошел “каждый онлайн-курс по программированию во вселенной”. В конце концов, не смотря на то, что он получил работу разработчика ПО, Квинси:

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

Ох. Звучит знакомо?

Эта статья предназначена для тех, кто уже знает про Docker, знает для чего он. А вот что делать с этим дальше не знает. Статья носит рекомендательный характер и не посягает на звание «лучшая практика».

Итак, возможно вы прошли docker tutorial, докер кажется простым и полезным, но вы пока не знаете, как он может вам помочь с вашими проектами.

Обычно с деплоем возникает три проблемы:

1. Как мне доставить код на сервера?
2. Как мне запустить код на серверах?
3. Как мне обеспечить одинаковость окружения, в котором запускается и работает мой код?

Как с этим поможет Docker под катом.

Глава 1. Спасибо, Майкл Дудикофф

В детстве я любил мечтать о том, кем же я стану, когда вырасту. Какой путь выбрать: космос или океанские глубины? Нет, я хотел создавать игры. Почему игры? Я рос во времена, когда разум любого мальчишки был отравлен компьютерным бумом и первыми консольными баталиями. Шли годы, мечта моя спала медвежьим сном, задавленная трудовыми буднями. И вот, однажды…

Март 2014. 7 утра в обычном московском спортзале. Поднимаю гантели, подавляя сонное недовольство разговорами с местными хохмачами. Тут в нашу беседу внезапно вклинился ОН.



Мальчики и девочки, рожденные на заре СССР, хорошо помнят гнусавый одноголосый перевод с затертых видеокассет. И вот один из обладателей того голоса появляется на экране ТВ, подвешенного к потолку. Конечно, я сразу узнал легендарного Майкла Дудикоффа, героя киноэпопеи «Американский ниндзя».

Предлагаю читателям «Хабрахабра» перевод статьи «Spotting bad actors: what your logs can tell you about protecting your business» из официального блога Elasticsearch. Статья рассказывает о том, как можно использовать возможности Elasticsearch для анализа логов веб-сервера с целью обнаружения подозрительной активности на сайте.

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

Но на сколько бы изменилась ситуация, если бы мы могли заблаговременно получать развернутую информацию обо всех IP-адресах и подсетях, которые проявляют подозрительную активность и блокировать именно их? Звучит здорово, не правда ли?

Мы можем легко сделать это вместе с Elasticsearch.

Привет, Хабр!

Мы в Хекслете любим свой стек технологий :) Когда рассказываем другим — многие завидуют: Rails, Docker, AWS, React JS. Реакт мы используем в первую очередь для создания веб-среды для разработки Hexlet-IDE, которая позволяет нашим пользователям выполнять упражнение по разработке приложений и взаимодействию с виртуальной машиной прямо в браузере.

Сегодня мы публикуем перевод статьи «An Unconventional Review of React» Джеймса Шора, ведущего проекта Let’s Code: Test-Driven JavaScript.



Он мне понравился. Я не ожидал такого.

Для специальных выпусков Let’s Code JavaScript в августе и сентябре я изучал Реакт.

На случай если вам не знаком Реакт: это библиотека для фронт-энд веб-разработки. С помощью него создаются компоненты: короткие, не-совсем-ХТМЛ теги, которые можно комбинировать для создания интерфейса.

Реакт знаменит своими нетрадиционными решениями: реализацией виртуального DOM’а, созданием элементов интерфейса в JavaScript вместо шаблонов, создание суперсета языка JavaScript — JSX, который позволяет вставлять не-совсем-ХТМЛ прямо в код JS.

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

Доброго времени суток. На данный момент я занимаю должность Senior/Team Lead IOS Developer. Так вышло, что за последний год мне довелось побывать на огромном количестве собеседований, так сказать, по обе стороны баррикад. Поэтому мне бы хотелось поделиться своим опытом и поговорить о том, как, на мой взгляд, надо проводить собеседование, ведь в общей суматохе можно упустить ряд важных моментов, что, впоследствии, может негативно отразиться на качестве собеседования.



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

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

В последнее время появилась масса биткоин сервисов. И то что раньше было проектом «for fun» неожиданно стало хранить десятки и даже сотни тысяч долларов. Цена биткоина выросла, но уровень безопасности биткоин сервисов остался таким же низким.

Ради портфолио мы провели бесплатный аудит биткоин биржи с открытым кодом Peatio использующей Ruby on Rails. Репорт в pdf можно скачать тут. Самое интересное что в результате нашлись не очередные унылые рейс кондишены или SQLi, а довольно таки любопытная цепочка багов ведущая к угону аккаунта и краже существенной части горячего кошелька.

Не так давно вышла статья, в которой автор описывал свой framework для написания приложений с использованием Ruby, Sinatra и websoсket. Но в том решении не был затронут вопрос горизонтального масштабирования. Так при подключении к одному из узлов, пользователи могут получать уведомления/данные только о событиях/изменениях, вызванных пользователями этого же узла, а при изменениях, внесенных через другой, они не узнают. Для решения данной задачи необходимо организовать общую шину данных. Рассматривать данную задачу буду в контексте обмена сообщениями клиент-клиент.

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

Сегодня мы приступим к созданию примера — разработаем API, которое умеет:
— регистрировать пользователя
— активировать его по email
— обновлять данные авторизованного пользователя
— возвращать профиль авторизованного пользователя