«Умные» часы Pebble стали рекордсменом по сбору средств на Kickstarter’e: их создателям удалось привлечь более 10 миллионов долларов. Устройство синхронизируется со смартфонами, позволяя использовать их функционал на самих часах. По сути, это наручный компьютер, на котором можно читать смс, управлять плейлистами в iTunes, получать уведомления из социальных сетей и отсчитывать количество пройденных километров во время пробежки.

Однако это проект стал не только самым успешным в истории Кикстартера, но и создал прецедент, из-за которого на сайте появился манифест «Кикстартер – не магазин». В нем основатели краудфандинговой площадки просят пользователей не относиться к проектам, как к продуктам в магазине. Дело в том, что Pebble не успел выполнить свои обязательства перед бэкерами в условленный срок, что спровоцировало бурю негодований и вызвало волну недоверия к крауд-проектам в целом.

Planeta.ru связалась с создателем часов Pebble Эриком Мигиковским (Eric Migicovsky) и задала ему несколько вопросов. Эрик отвечал лаконично и по делу.



— Эрик, почему вы решили использовать краудфандинг, а не занялись поиском инвестора?
— В феврале 2012 года не было инвесторов, готовых вложить деньги в наш проект, поэтому мы решили разместить его на Kickstarter.
— Сколько прошло времени с момента решения использовать kickstarter до запуска кампании?
Может быть, один-два месяца.
— С какими трудностями вы столкнулись в ходе кампании?
Самым сложным этапом была работа над прототипом Pebble, а также над видео и контентом для страницы проекта.
- Сколько времени вы тратили на ведение проекта?
В течение первых двух недель кампании мы работали по 12 часов в день только на проект на Кикстартере. После этого я нанял людей и занимался исключительно дизайном.
- Ожидали ли вы такого успеха? И с чем вы его связываете?
— Если честно, мы такого не ожидали: первоначально планировали привлечь $100,000. Вероятно, нам повезло, и сочетание дальновидности, стратегии и удачи сработало!

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

В то же время за пределами университетов начала складываться совершенно новая экосистема получения и, что очень важно, подтверждения и сертификации знаний и навыков. Профиль на LinkedIn, репозитории на GitHub, сертификаты от серьёзных корпораций вроде Cisco или Microsoft, результаты авторитетных онлайн-тестов сегодня часто могут заменить формальный документ об образовании.

Degreed стремится к амбициозной цели — создать единый пожизненный цифровой диплом, постоянно обновляемый и гибкий, который будет отражать реальные знания независимо от того, из какого источника они получены. Вы можете прослушать несколько курсов в одном университете, ещё несколько — в другом, или вообще на сайте вроде Coursera или Khan Academy — баллы в вашем «дипломе» будут увеличиваться в зависимости от авторитетности курса и ваших личных достижений.

На WWDC 2012, которая проходила в июне этого года, среди нововведений был представлен Social framework. Это фреймворк даёт возможность интегрировать кнопки шаринга в социальных сетях быстро и просто. Social framework вытеснил Twitter framework, представленный в iOS 5. Теперь у нас есть возможность интегрировать не только Twitter, но также и Facebook и Weibo (китайский аналог Twitter) в наши приложения без лишних заморочек.

В этой статье собраны полезные  и «правильные» стили и сниппеты, которые помогут ускорить процесс разработки сайта, а также оптимизировать верстку.

Всем привет!
Не секрет, что мы, программисты, минимум половину времени тратим на написание кода. Логично было бы это время как можно лучше сократить.
Однажды, когда я в очередной раз написал конструкцию NSString *, я подумал, что пора что-то менять.
Как же можно упростить себе жизнь, разрабатывая под iOS?
Статья является расширением другой статьи

Git – это не только удобная распределенная VCS, но и инструмент подготовки релизов.
В статье будет рассмотрен flow на примере Java-проектов на Maven. Статья может быть полезна для разработчиков малых и средних команд, подразумеваются базовые знания git. Материал частично перекликается с git-flow, но здесь описан более простой вариант.
В классическом случае в репозитории существует одна ветка master, из нее же делаются сборки. Если проект собирается при этом на build-сервере, это может привести к беспорядку – несколько разных билдов под одной версией, не ясен набор коммитов, которые попадают в релиз (например, если сборка делается автоматически по триггеру на VCS).

Часто замечаю, что большинство программистов, разрабатывающих приложения для Android, не в курсе последних новостей Android Community. Если о появлении новой версии ОС знают практически все, то выход различных полезных библиотек или интересных для разработчиков статей часто остается незамеченным.

За последний год у меня сформировался список контактов в соц. сетях наиболее известных личностей из Android Community. Эти люди регулярно пишут статьи, публикуют библиотеки, отвечают на StackOverflow и т.д. Подобный список помогает одному из первых узнавать новости сообщества Android Developers, поэтому решил поделиться им здесь.

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

Все мы знаем, что такое iPhone. Мы примерно знаем, кто его придумал и за счёт чего он стал таким популярным. Мы знаем, что пятая версия длиннее, чем 4S, и что у неё выше разрешение экрана. Мы знаем, что в iPhone 4S два ядра вместо одного в iPhone 4 и кучу других деталей. Наконец мы знаем, что проект коммерчески невероятно успешен, и вывел Apple из производителя железа для гиков и профессионалов в мейнстрим, сделав её из самых богатых компаний мира.

Внимание, ключевой вопрос: можем ли мы воспроизвести iPhone? Повторить его. Ничего не выдумывая, взять и сделать точно такой же или хотя бы нечто, отдалённо его напоминающее? Пусть даже самую простую, старую и слабую его модель? Своими руками отлить из металла спаять, собрать, свинтить, скрепить, вырезать, вырастить…

Приветствую, уважаемые читатели Хабрахабра. Хочу поделиться с вами своим опытом использования backbone.js под node.js. Ранее я активно поработал с backbone.js на клиенте, и эта библиотека оказалась крайне удобной для структурирования кода.

Сервис без работы с какой либо базой данных — не сервис. В моем случае, в качестве СУБД была выбрана mongodb. Я посмотрел существующие решения ORM для mongodb, и мне показалось более удобным пользоваться знакомыми инструментами, тем более они же будут использоваться и на клиенте, поэтому решено было попробовать применить для моделей класс Backbone.Model и заодно проверить, как все это можно кастомизировать под mongodb.

Перевод статьи из блога Matthew Cashdollar

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

Долгих лет жизни читающему эти строчки.
В статье обобщен трехлетний опыт создания iOS игр для личного пользования.
Примеров программного кода не будет. За примерами программного Вы идите на stackoverflow.com.

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

Лентяям предлагаю посмотреть видео-ролик.


Остальных приглашаю в мир букв и забавных событий.

Целевая аудитория: системы, которым нужна несложная CMS, не влияющая на архитектурное решение. (CMS, как хранилище контента, без генерации форм и т.п.)

Цель данной статьи – в «2х словах» показать, как можно использовать Umbraco CMS в качестве источника данных, от которого глобально не зависит основное приложение (ведь источник в любой момент можно заменить на любой другой), другими словами, как вынести CMS в отдельный проект.

Некоторое время назад я узнал об Umbraco CMS, которая сразу привлекла мое внимание. Одним из основных ее преимуществ для меня явилось ее free openSource, со всеми вытекающими. Достаточно простой и эффективный дизайн, несложный бэкграунд, большое комьюнити и широкий ассортимент бесплатных расширений. С полным списком преимуществ и недостатков можно ознакомиться в сети. Меня огорчили всего два момента:

1. СMS предъявляет определенные претензии к структуре и платформе основного приложения, роутингу и т.п. Программирование на C# сводится к написанию User-контролов.
2. Исходя из первого пункта, на данный момент последнюю версию (4.10) невозможно использовать с ASP.NET MVC, который я так люблю. (видел в сети вариант с проектом «смешанного типа» — ASP.NET + ASP.NET MVC, но мне он тоже не понравился)

Мне же хотелось использовать CMS исключительно как модуль администрирования контента, данные которого я мог бы получить просто подключив пару-тройку библиотек к любому другому проекту. И, насколько я понял, Umbraco не предоставляет такой возможности по умлочанию. Кроме того, мне хотелось бы самостоятельно писать разметку страниц, логику биндинга данных на C#, определять layout, не возится с xslt, на котором построен ui-engine umbraco. Проведя некоторое время в поисках и не найдя ничего подходящего пришлось решить эту задачу самостоятельно.

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

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

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

Добрый день, хаброжители. Прошло много времени с выпуска 2 версии книги по PostgreSQL — успела выйти версия 9.1 и 9.2 этой замечательной базы данных. Материалов по практическому использованию этой БД также накопилось немало, поэтому я решил выпустить обновление по книге. Итак, встречайте:«Работа с PostgreSQL: настройка и масштабирование», 3-е издание.

Как и раньше, в книге исследуются вопросы по настройке производительности PostgreSQL, репликации и кластеризации. Список изменений можно глянуть на странице книги. Любые пожелания или замечания можно высылать по почте (в моем блоге указано) или писать в github issues (или даже делать pull request на исправления). Приятного прочтения!

Страница книги: postgresql.leopard.in.ua
Исходники: github.com/le0pard/postgresql_book

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

С помощью вычислительного графа можно установить зависимости между задачами и в какой-то мере программно реализовать «dataflow архитектуру».

В этом посте я опишу, как реализовать такую модель на С++, используя библиотеку Intel Threading Building Blocks (Intel TBB), а именно класс tbb::flow::graph.

С недавнего времени я интересуюсь языком Scala. Пару месяцев назад я набрел на интересную серию статей от компании Twitter. Я сносно читаю на английском, но все же приятнее читать на русском языке, если есть нормальный перевод.
Благодаря труду Мариуса Эриксена (Marius A. Eriksen) и других людей серия статей увидела свет. Всех желающих узнать больше о Scala и помочь в улучшении перевода — приглашаю под кат.

Введение

Современный темп разработки ПО просто поражает своей скоростью. Функционал всегда «нужен вчера». Зачем? Конкуренция — обойдут, обгонят. Времени тестировать нет, надо отгружать функционал, надо, надо, надо.

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

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

В итоге мы получили три языка программирования — R.Script (микропроцессоры, вычислительные программы), L.Script (GUI, Web приложения) и главный — W.Script (этот язык — основа двух предыдущих и с ним можно делать все, что хочешь).

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

Существует множество компаний, которые продают товары клиентам или оказывают какие-то услуги. Часто продавцы интуитивно принимают решения, какой именно товар из всей существующей линейки лучше подходит клиенту. Также интуитивно определяется, какой массив клиентов более интересен для компании, а для каких клиентов продажа и дальнейшее обслуживание будут слишком затратные и невыгодные.
Для технологичного понимания всех этих вопросов хорошо подходит анализ информации с помощью технологии Data mining. Автоматизируя процесс сегментации клиентов с помощью кластеризации Data mining, компания может найти ответы на множество вопросов.
Рассмотрим вариант, когда компания занимается продажей товаров или услуг и дальнейшим послепродажным обслуживанием. Соответственно у компании есть потенциальные клиенты, которым осуществляются продажи. Также есть клиенты, которые обслуживаются или были ранее на обслуживании, т.е. которым ранее уже продавали. Для простоты будем их называть обслуживаемыми клиентами.
Кратко опишу цель и идею. Для анализа необходимо взять несколько показателей (15-20), которые есть у потенциальных и обслуживаемых клиентов одновременно. Также надо выбрать 2-3 показателя, которые есть только у обслуживаемых клиентов – это целевые показатели. Провести анализ кластеризации Data mining на массиве обслуживаемых клиентов. На выходе получим несколько кластеров со своими характеристиками. Далее кластеры группируем в сегменты по целевым показателям и даем какие-то понятные для маркетологов определения. Полученную модель анализируем, и полученные кластеры проецируем на потенциальных клиентов. На выходе получаем просегментированных потенциальных клиентов. На основании полученных сегментов можно выстроить стратегию и методологию продаж для каждого сегмента клиентов.
Рассмотрим подробнее данную методику и последовательность шагов для достижения результата.

Я люблю откладывать

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

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

Бла, бла, бла, продуктивность системы… откладывание со дня на день… бла-бла-бла!

Я знаю, вы слышали все это раньше, но вот что странно: я почти всегда получаю вещи, сделанные хорошо, задолго до срока.

Так в чем моя проблема?

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