Не обманывайте ни меня, ни себя. Любой человек хочет продать свой стартап. Все мы разглагольствуем о том, что хотели бы создать компанию, приносящую миллиарды долларов, типа Groupon. Но, как правило, все эти заявления – ложь. Даже Ларри Пейдж и Сергей Брин собирались продать Google Yahoo за 1 миллион долларов через 10 секунд после образования компании. Но компания Yahoo сказала «Нет».

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

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

Код доступен для ознакомления на гитхабе. Образы опубликованы на докерхабе, весь зоопарк стартует одной командой.

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

Данное тестирование проведено было скорее для собственного интереса. Т.к. ORM много, все они разные, и хотелось бы иметь объективное представление о существующих системах.

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

Разберем процесс, как это обычно происходит. Аналитик получает запрос на изменение функционала в виде тикета из техподдержки, технического задания или прямой жалобы клиента. Суть запроса в том, что что-то там в системе плохо и нужно подумать, как это исправить. Или что нужно сделать вот тут на этом экране еще одну такую возможность. Или нужно, чтобы «у пользователя была возможность сделать вот это». Часто аналитик просто записывает требование в том виде как оно пришло: в виде нескольких предложений или user story, формирует из этого задачу на изменение (или несколько задач) и отправляет её разработчику. Далее происходит то, что описано в последнем предложении предыдущего абзаца. Разберемся почему.

MVP это не просто продукт с половиной урезанных фич. По факту, MVP не является продуктом вообще. И это, конечно, не то что вы сделали один раз и считаете что работа уже окончена. Скорее всего, вы вообще не понимаете, что это такое.

Я бэкенд Java-разработчик, и до фронтенда руки доходят очень редко. Это большое упущение. Отсутствие представления о фронтенде не даёт мне увидеть полную картину мира. Я не знаю, на что обращают внимание и как пользуются всеми модными средствами вроде Node.js, Gulp, Webpack, то есть тем, что так пугает бекенд разработчиков своим разнообразием и постоянными переменами.

И первой моей жертвой целью стал Dillinger.io. Это открытый текстовый редактор для Markdown, в нём есть подсветка синтаксиса и экспорт написанного текста в PDF, HTML, Dropbox, Github и Google Drive, также можно добавить собственный способ, к примеру, статический генератор сайтов или Wordpress.

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

Полгода назад за чашечкой кофе программист, режиссер и геймдизайнер вели дружескую беседу на тему того, что кинематограф становится скучным. «Да, спецэффекты становятся круче, количество D становится больше, но этим сейчас малого кого можно удивить. Людей цепляет сюжет. А теперь представьте, что когда-нибудь мы будем смотреть смотреть фильмы, которыми можно управлять?»
— Я бы убил Джона Коннора.
— А я бы не выбросил бузинную палочку и стал плохим волшебником.
— А я бы на месте Поттера воспользовался маховиком времени, чтобы спасти его родителей, а не клювокрыла.



И, как говорится, понеслось…

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

Автор: Mike Gouline
https://blog.gouline.net/2015/06/23/code-coverage-on-android-with-jacoco/
Перевод: Семён Солдатенко

С тех пор как эта возможность появилась в Android Gradle плагине версии 0.10.0 было написано много статей об измерении покрытия кода тестами (test coverage) — и я не испытываю никаких иллюзий по этому поводу. Однако, что меня раздражает, так это необходимость заглядывать в несколько таких статей и даже в документацию Gradle прежде чем вы получите полностью работающее решение. Так что вот, еще одна статья которая попытается это исправить и сберечь ваше время.

Именно плохие привычки мешают бедным людям разбогатеть – такое заключение сделали специалисты Университета Браун. Они провели масштабное исследование, на которое понадобилось 5 лет. Речь идет не о переедании, курении или чистке зубов по праздникам. Все гораздо серьезнее.

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

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

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

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

Предлагаю вашему вниманию перевод статьи из блога сервиса Wrike. Посвящен он теме проведения эффективных мозговых штурмов.

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

Привет, хабравчанин!

В этой заметке речь пойдет о Plotti.co — адски простом в использовании инструменте, который делает ровно одну вещь, но делает её быстро и хорошо. Речь пойдет об онлайн-рисовании графиков и их обновлении в реальном времени.

Создание живых графиков на лету, как мне кажется, не является той задачей, для решения которой нужно сперва прочесть 10 страниц документации, заплатить за подписку по $20 в месяц, а иногда — и то, и другое сразу. Так нельзя. Не в 2016 году.



В Plotti.co клиентская часть — это SVG-изображение, которое подписывается по EventSource на источник данных от сервера, и обновляет график в соответствии с ними. Интегрируется она в страницу элементарно:

<object data="http://plotti.co/U0N5G5FQigwC/plot.svg" type="image/svg+xml"></object>

Да, это всё. Здесь U0N5G5FQigwC — это хеш картинки. Чтобы картинка обновилась во всех браузерах, в которых она сейчас открыта, необходимо просто послать GET-запрос по соответствующему адресу. Например,

wget "http://plotti.co/U0N5G5FQigwC?d=1.5,3.6,7.8mbps" -O /dev/null

Автор: Вячеслав Михайлов, Solutions Architect.

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

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  
  • XML-RPC and JSON-RPC
  • SOAP
  • REST
  
  
• WebSockets APIs
• Library-based APIs
  
  • Java Script
  
  
• Class-based APIs
  
  • C# API
  • Java
  
  

Виды API по категориям применения:

• OS function and routines
  
  • Access to file system
  • Access to user interface
  
  
• Object remoting APIs
  
  • CORBA
  • .Net remoting
  
  
• Hardware APIs
  
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …
  
  

Стараясь оставаться в тренде и следуя веяниям моды веб разработки, последнее веб приложение я решил реализовать как набор микросервисов на ruby плюс “толстый” клиент на ember. Одна из первых проблем, вставших перед мной была связана с аутентификацией запросов. Если в классическом, монолитном, приложении все просто, используем куки, сессии, подключаем какой-нибудь devise, то тут все как в первый раз.

Архитектура

За базу я выбрал JWT — Json Web Token. Это открытый стандарт RFC 7519 для представления заявок (claims) между двумя участниками. Он представляет из себя структуру вида: Header.Payload.Signature, где заголовок и payload это запакованые в base64 json хэши. Здесь стоит обратить внимание на payload. Он может содержать в себе все что угодно, в принципе это может быть и просто client_id и какая-то другая информация о пользователе, но это не очень хорошая идея, лучше передавать там только ключ идентификатор, а сами данные хранить где-то в другом месте. В качестве хранилища данных можно использовать что угодно, но мне показалось, что redis будет оптимальным, тем более что он пригодится и для других задач. Еще один важный момент — каким ключем мы будем подписывать наш токен. Самый простой вариант использовать один shared key, но это явно не самый безопасный вариант. Коль скоро мы храним данные сессии в redis, ничто не мешает нам генерировать уникальный ключ для каждого токена и хранить его там же.

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

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

Штат Google насчитывает более 60 000 специалистов, а также компания обладает всевозможными ресурсами, чтобы создавать оригинальные сервисы в добавок к поисковой системе и другим крупным проектам. Ниже представлена подборка занимательных и полезных приложений от Google. От поиска информации в исключительно профессиональных изданиях до географических карт, составленных из фотографий обычных людей.

1. Google Keep

Google Keep — это бесплатное интернет-приложение, предназначенное для создания и хранения заметок. Работает как на настольном компьютере, так и на телефоне. Его красочный дизайн поможет Вам создать уникальный и яркий список дел. Можно установить «напоминания», которые будут объединены с GCal.



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

К концу 2015 года в распоряжении JavaScript разработчиков образовалось огромное количество инструментов. В этой экосистеме легко потеряться, поэтому успешные команды следуют выработанным правилам, которые позволяют не терять время и сохранять здоровье проектов. Под катом перевод статьи 2016 года от команды Heroku, в которой они рассказывают о десяти привычках веб разработчиков, у которых все работает и ничего не болит. Скорее всего 80% написанного вы уже знаете – тем интереснее вам будет прочитать об оставшихся двух приемах!

Что если я расскажу вам как без особых усилий поднять свой собственный jabber-сервер со всеми новомодными фичами, такими как: архивация, синхронизация сообщений между клтентами, уведомления о прочтении, публичные чаты и многое другое…
Так же поделюсь с вами замечательным Jabber-клиентом который не менее интересен, он поддерживает аудио и видео звонки, имеет неплохой интерфейс и работает прямо из браузера.
То и другое вы получите абсолютно бесплатно, так-как и сервер и клиент лицензируются по свободнлй лицензии.

Речь пойдет об Metronome IM и Jappix.

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

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

Этот мир просто охренеть какой сложный, каждый день поражаюсь.

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

И знаете, что удивительно? Этот подход замечательно работает. Ну, почти всегда. По крайней мере, ничего лучше мы до сих пор не придумали.

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



Да, я о клеточных автоматах, а именно — об их подмножестве, простейших клеточных автоматах (Elementary cellular automaton). В этой статье я поведаю, что это такое, какие они бывают, какими свойствами обладают, а также отвечу на главный, на мой взгляд, и совершенно правильный вопрос, который часто несправедливо игнорируется в подобных статьях. Звучит он так: А это всё вообще зачем?

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

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