Преамбула

Когда-то давно, работая еще в ZendStudio 5.0, а потом и 5.5 нашлась красивая темная тема для подсветки кода. За пару лет работы я так привык к ней, что пересев на Eclipse+PDT, глаза были против белого фона с зелеными буковками.
Поиски в интернете такой же темы для Eclipse, поиски хоть какой-нибудь тёмной темы а затем и поиски вообще какой-либо темы результата не дали. Оказалось (о ужас!), что Eclipse не поддерживает смену готовых тем.

Поиски хотя бы какой-то возможности кастомизации Эклипса на хабре вывели на топик хабраюзера olegchir. Вдохновленный идеей самому сделать аналог Parabox Style для Eclipse, я принялся за работу

Что из этого получилось, можно глянуть на скриншотах ниже:

DROD — весьма необычная логическая игра. Главные ее особенности:

• Пошаговость. В отличие от supaplex реакция не имеет значения.
• Детерменированность. Элемент случайности отсуствует, любую позицию можно просчитать в уме, хотя обычно это очень не просто сделать.
• Большое концептульное разнообразие головоломок. Благодаря этому игра надоедает гораздо медленнее чем, например, судоку.
• Приключенческий антураж, придающий смысл процессу (в основной миссии мы делаем виртуальный мир DROD чуточку чище).

Головомки состоят в том, чтобы убить всех монстров в комнате 38x32 клетки. Игрок управляет персонажем занимающем 1 клетку, который держит меч, занимающий еще одну из 8 соседних клеток. Каждый ход можно либо пойти на одну из 8 соседних клеток, либо повернуть меч, либо подождать. После чего по очереди ходят оставшиеся в живых монстры. Если они смогут занять клетку, на которой стоит игрок, он проигрывает и возвращается к началу комнаты.



Дополнительный интерес к игре придает таблица рекордов скорости (по количеству ходов) прохождения комнат. Она-то и является нашей целью. Но как можно применить компьютер к игре, с концептуально различными головоломками и астрономическим количеством вариантов (в каждый момент у нас 11 вариантов хода, а общее число возможных состояний комнаты на много больше чем в шахматах)?! Выход один — переложить интеллектуальную часть задачи на человека, а рассчетную (оптимизация решения по количеству ходов) — на компьютер.

Кто тут начальник, а кто — подчинённый?

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

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

Статус собеседников

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

Приёмы игры высокого [низкого] статуса

Зачем нужны камеры наблюдения? Правильно — чтобы наблюдать за происходящим и контролировать ситуацию! В наше неспокойное время эти самые камеры развешаны повсюду — от денежных хранилищ до придорожных кафе. Однако защищая свои владения, хозяева порой забывают о защите самой камеры путем банальной установки пароля на доступ из Интернета. И очень зря. Если пароль не установить — ваша камера «безопасности» превращается в публичную вэб-камеру с реалити шоу для всех желающих.

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

Критерии

Многие скажут – нанимайте умных. Особенно это актуально для нашей индустрии. Вы прочтёте: «нанимайте самых умных, и успех у вас в кармане». Я считаю, что сам по себе интеллект слишком переоценен. Я не видел статистики, которая бы подтверждала зависимость между чистым интеллектом, измеренным любым способом (достижения в образовании, тесты интеллекта, способность решать логические задачки) и успехом компании.

Добрый день, уважаемые Хабражители.

AngularJS — отличный Framework для создания ваших сайтов. На Хабре уже достаточно много про него написано, но почему то ни разу не затрагивалась тема локализации приложений. Тем не менее, поддержка локализации в нем есть и сегодня мы попробуем с ней разобраться.

Существует несколько способов локализации и мы рассмотрим несколько из них.

После прочтения Google's AngularJS Guidelines у меня создалось впечатление о его незавершённости, а ещё в нём часто намекали на профит от использования библиотеки Closure. Ещё они заявили, «Мы не думаем, что эти рекомендации одинаково хорошо применимы для всех проектов, использующих AngularJS. Мы будем рады видеть инициативу от сообщества за более общий стайлгайд, применимый как для небольших так и крупных проектов».

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

В давние времена разработки мобильных сайтов и приложений отладка была сложной задачей. Да, можно было заполучить устройство и быстренько проверить работу – но что было делать, если ты обнаруживал баг?

При отсутствии инструментов отладки приходилось полагаться на разные хаки. В целом они сводились к попыткам воспроизвести баг в десктопном браузере и затем отловить его при помощи Chrome Developer Tools или где-то ещё. К примеру, можно было уменьшить размер окна браузера или поменять user agent.

Грубо говоря, эти хаки не работали. Если ты правишь баг на десктопе, ты не уверен, что он исправлен на мобильном устройстве (МУ). Поэтому приходилось постоянно метаться между устройством и десктопом.

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

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

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

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

В последний год мы написали много статей по UX / UI проектированию eCommerce проектов и не только. Концепция проекта и интерфейсы – это, безусловно, очень важно, однако есть еще несколько крайне важных вещей, которые нужно учесть. Не важно, кто их будет учитывать: UX / UI Designer, SEO Specialist, Web Developer, Project Manager или кто-то еще, важно на каком этапе жизни проекта. А сделать это нужно задолго до запуска проекта, на этапе разработки.

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

1. Robots.txt. Файл для правил индексации поисковыми системами. Создать и положить в корень сайта. В идеале индексация должна быть открыта всем поисковым системам и всему сайту (за исключением закрытых разделов, таких, как личный кабинет).
2. Файл Sitemap.xml. Карта сайта для поисковых систем. Создать и положить в корень сайта. Сделать автогенерацию с заранее заданным весом страниц разбитым по типам информации (например, страница товара 8, страница категории 9, страница статьи 7 и т.д.). Загрузить файл в поисковые системы.
3. Карта сайта. Кроме Sitemap.xml еще желательно сделать отдельную страницу на сайте, дать ссылку на неё в нижней части сайта и также поместить ссылки на основные страницы. На одной странице не должно быть больше 300 ссылок. Если на сайте больше страниц, то проблему можно решить через пагинацию внизу страницы «Карта сайта».

Зачем вам это?

• Если вы знаете как делать сайт, этот метод поможет вам убедить заказчика, почему вы предлагаете ему именно этот вариант.
• Если вы заказываете сайт, то сэкономите от 2 до 10 часов объяснений что вам нужно и зачем.
• Если вы стартапер, то вся ваша команда сможет участвовать в создании нового сайта или лэндинга. Тот самый случай, когда одна голова хорошо, а команда лучше.
• Если вы учите стартаперов, то сможете помочь им выглянуть из позиции «я знаю как надо» и без сопротивления подвести их к началам CusDev-a.

Graphana — первый действительно хороший дашборд для отображения метрик.

После выхода Intel XDK (обзорная статья на habrahabr здесь ) нас часто просили предоставить возможность пользоваться сторонними плагинами для Cordova и возможность монетизировать созданные приложения с помощью Google AdMob и In-App Purchases. И мы это сделали в обновлении Intel XDK (по прежнему доступном для бесплатного скачивания и использования здесь, русскоязычное обзорное видео здесь).

Мы живём в удивительное время, ещё 10 лет назад робототехника была чем-то фантастически недоступным. Сейчас же на базе Ардуино, набора серво-двигателей, лазерной резки и 3д печати можно сделать разнообразные проекты — и это будет вполне доступно по финансам и по навыкам (собрать может школьник).

Примером одного из таких проектов является — Робоголова.

Этот проект был найден среди kickstarter проектов. Плюсом является то, что разработчики выложили все инструкции по сборке в OpenSource.

Для создания потребуется:

• лазерная резка (фанера)
• 3д печать (элементы глаз)
• Ардуино (микроконтроллер)
• серво-двигатели
• крепежные элементы

Начнём.

Господа, рад представить вам свой новый проект — Refactoring.guru.

Сайт представляет собой каталог запахов грязного кода и, собственно, самих приёмов рефакторинга. В двух словах — это как книга Мартина Фаулера, но лучше. А именно:

• Весь контент доступен на русском языке. Я старался делать описания как можно более живыми, чтобы избавиться от чувства унылости и скуки, которое возникает при чтении любой переводной книги о рефакторинге.
• Все примеры подаются на Java и PHP. Другие языки обязательно будут добавляться со временем, но я пока затрудняюсь решить, каким будет следующий, можете предлагать в комментах.
• Всё везде перелинковано. Рефакторинги сгруппированы по предназначениям и связям.

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

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

Буду рад всем отзывам и пожеланиям! (а также лайкам и твитам)

Предисловие переводчика: В мире написано столько книг по личной эффективности и тайм-менеджменту, что берясь за этот перевод я безусловно задавал себе вопрос: «А есть ли здесь вообще что-то новое, ради чего эту статью стоит переводить, и главное читать»? Сначала мне казалось, что я ответил на этот вопрос «да», однако реальность оказалась несколько сложнее. 

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

1. Согласен ли я с написанным?
2. Если да, поступаю ли я так?
3. Если нет, почему и что я могу сделать чтобы начать поступать правильно? 

Уверен, так статья принесет вам гораздо больше пользы.

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

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

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

Приятного чтения!

Я, будучи разработчиком мобильных приложений, часто нуждаюсь в backend-сервисах для хранения пользовательских данных, авторизации и прочего. Конечно, для подобных задач можно использовать BaaS (Parse, Backendless, etc…). Но свое решение — это всегда более удобно и практично.

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

В данной статье будет рассмотрено построение REST API для мобильного приложения на Node.js с использованием фреймворка Express.js и модуля Mongoose.js для работы с MongoDB. Для контроля доступа прибегнем к технологии OAuth 2.0 с помощью модулей OAuth2orize и Passport.js.

Пишу с позиции абсолютного новичка. Рад любым отзывам и поправкам по коду и логике!

Содержание

1. Node.js + Express.js, простой web-сервер
2. Error handling
3. RESTful API endpoints, CRUD
4. MongoDB & Mongoose.js
5. Access control — OAuth 2.0, Passport.js

Всем привет!

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

Автор картинки: Donovan Shortey, использовано по лицензии Creative Commons.

Познавательная книжка Discover Meteor теперь переведена усилиями сообщества на русский язык и находится в свободном доступе. Английская версия по-прежнему требует подписки и стоит (разумных) денег.

В начале марта авторы оригинальной книжки Sacha Greif и Tom Coleman бросили клич, приглашая любителей фреймворка MeteorJS перевести ее на все языки мира. Локализированные версии книжки выкладывались бы под свободной лицензией Creative Commons, свободно доступные для всех желающих быстро познать мир Meteor. В настоящий момент существуют переводы на 22 языка мира, в разной степени готовности. Проект доступен на GitHub, и если кто-то заметил опечатку, или желает как-то дополнить перевод — добро пожаловать в команду.

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