Странное дело, порой кажется что каждый месяц появляется не меньше дюжины новых GTD-like таск-менеджеров. Одновременно с этим, хороших приложений для эффективного управления повседневными задачами крайне мало. Думаю, редкий читатель нашел для себя подходящий инструмент и пользуется им повседневно.
Мы не из ленивых, и как вы уже догадались, тоже сделали свой, с… всем что полагается.
Ниже я расскажу о нашей парадигме и особенностях, которые выгодно отличают нас от конкурентов. Т.к. многие уже устали от обилия постов о личной продуктивности на Хабре, в своем рассказе я сделаю упор на веб-технологии, а не на gtd-методологию. А пока картинка для привлечения внимания:

Посетителям сайта stackoverflow.com был задан вопрос: «Какие программерские термины вы придумали, так чтобы они стали популярны в ваших кругах (то есть вы слышали, что кто-то их повторяет)?

Ниже — вольный перевод самых популярных ответов.

Все мы прекрасно понимаем, что тестирование является неотъемлемой частью жизненного цикла разработки ПО. Чем чаще мы тестируем наш код, тем быстрее мы сможем обнаружить ошибку, вкравшуюся в него в ходе разработки, и быстрее её исправить. При этом стоит понимать, что тестирование крайне желательно проводить в окружении, максимально близком к боевому (ОС, ПО, Hardware, Нагрузка), что бы иметь возможность обнаружить ошибки, которые не проявляются на сервере разработки, но могут появиться в бою. Компануя два вышесказанных тезиса вместе мы получаем концепцию, называемую Continuous Integration.

Суть CI заключается в постоянной (например, после каждого commit'а) сборке и тестировании разрабатываемого ПО в максимально приближенной к боевой среде с целью как можно более раннего обнаружения ошибок и оповещения о них разработчиков. Сама идея CI принадлежит Martin Fowler, подробно описавшему её в своей статье.

Для автоматизации процесса непрерывной сборки существуют готовые решения (Hudson, CruiseControl), интеграцию одного из которых (Hudson) я и опишу в этой статье.

В этой статье будет описано архитектурное решение низкого уровня облачной платформы Hivext, а именно уровня дата центров и взаимодействия между собой серверов разного типа.
Напомним, что проект Hivext — предназначен для более эффективного использования ресурсов (временных и финансовых) при разработке “богатых” интернет приложений (Rich Internet Application) и предоставляет широкий набор готовых взаимосвязанных сервисов.
Благодаря компании IT-GRAD мы получили возможность бесплатного разворачивания дополнительной копии платформы в Питерском дата центре (ДЦ). Нам выделили виртуальный хостинг на базе VMware vSphere 4. Работать с таким хостингом можно и через веб интерфейс и через десктоп клиент, все довольно удобно.

На данный момент Hivext развернута в 3-х территориально разнесенных ДЦ: Киев (Украина), Житомир (Украина) и Санкт-Петербург (Россия). Конфигурация платформы внутри каждого ДЦ построена по определенной структуре.

Предлагаю, так сказать, заглянуть под капот нашей платформы.

Беспрецедентные объемы данных заставляют разработчиков и бизнес приглядываться к альтернативам реляционных баз данных, используемым вот уже более тридцати лет. В совокупности все эти технологии известны как «NoSQL базы данных».


Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о high-load проектах). Есть три конкретные проблемных области:

• горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)
• производительность каждого отдельного сервера
• не гибкий дизайн логической структуры.

Самая мощная команда в MySQL – это EXPLAIN. EXPLAIN может в точности рассказать вам, что происходит, когда вы выполняете запрос. Эта информация позволит вам обнаружить медленные запросы и сократить время, затрачиваемое на обработку запроса, что впоследствии может значительно ускорить работу вашего приложения.

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


Поехал за книгой в магазин. А пока некоторые отрывки из книги и комментарии:

Вступление

C системой Аллена меня познакомили около двух лет назад. Начинал пользоваться вариантом Васи Кислого с помощью HTC Touch Pro, но глючность девайса сильно мешала освоить систему, а сам «Успеватель» не давал необходимого уровня понимания. С GTD пришлось на время расстаться.

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

Попытки вести мобильную версию системы в Nokia E63 с помощью «Активных заметок» привели к покупке книги Дэвида Аллена, переработке статьи В. Кислого, приобретению стабильно работающего, хоть и старенького HTC P3400 (а потом и более современного продукта от HTC) и введению бумажной, физически ощутимой части этой системы.

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

Следуя этим принципам, я прихожу на работу к 11-12 часам, работаю плотно и не отвлекаясь до 15 часов. В 15 часов ухожу в зал потаскать железки, прихожу в офис к 17-30, прорабатываю за полчаса все накопившееся с 15 часов. И еду домой.

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

Кому интересно, прошу под кат.

Приветствую, Хабрахабр.

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

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

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

Итак, бизнес. Преимущественно мы говорим о т.н. стартапе, когда бизнес основывается с нуля. Вы приняли это решение, и неважно, как вы к нему пришли — возможно, у вас появилась идея, возможно, вам просто не хочется просто работать на кого-то. Есть распространенное мнение о том, что для бизнеса нужен существенный начальный капитал. Начальный капитал необходим, но не обязателен, и существует ряд успешных примеров бизнеса, основанного практически на карманные расходы. Как говорит один из моих профессоров, бывший член совета директоров Exxon Enterprises и Genesis Group – «основывая стартап, не заботьтесь о капитальных вложениях, просто докажите, что ваш бизнес способен приносить доход и что вы способны им управлять, и тогда у вас не будет недостатка в капитале».

С чего начать?

Говорят, что идеи ценятся дороже любых драгоценностей и предметов искусства и при грамотном использовании могут принести миллионы долларов. Говорят, что если к вам в голову пришла интересная идея, то её нельзя никому рассказывать, а надо найти богатого инвестора и продать идею ему за большие деньги. Говорят, что идею надо обязательно запатентовать, иначе богатые инвесторы украдут идею и не заплатят денег. Говорят, что те кто так сделал — сейчас сказочно богаты, купили себе остров и живут там как в сказке. Говорят… А кто говорит-то? Да все вокруг! Друзья, коллеги, знакомые, родственники. А так ли это на самом деле?

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

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

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

Если верить статье, интерес к «ПроГороду» проявила также и Федеральная антимонопольная служба, которая якобы заподозрила в действиях производителей «ПроГорода» демпинг. В общем, написано там было много обидных вещей, и неудивительно то, что «Сидиком» подал в суд иск о защите деловой репутации. Суд иск удовлетворил частично, отказав в опровержении большей части утверждений, по одному из самых распространенных оснований в делах такого рода: большинство сведений, распространенных ответчиком, были признаны «мнением», которое нельзя ни проверить на истинность, ни опровергнуть… Ну, а поскольку вопрос об истинности слов про нарушение картографами «интеллектуальных прав» на спутниковые снимки судом по существу не рассматривался, то рассмотреть его придется нам, в рамках этой статьи.

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

1 Коротко и неясно

1. ЧИТАЙ КОД!
   
2. Пиши код, который удобно читать всем остальным
   
3. Пиши в комментарии не ЧТО делает код, а ЗАЧЕМ
   
4. Предупреждения и подсказки опаснее ошибок компиляции — проект собирается без их устранения
   

2 Цикл разработки

1. Постановка задачи руководителем
   
2. Выработка решения
   
3. Рецензирование решения
   
4. Реализация решения
   
5. Рецензирование кода
   
6. Размещение в системе контроля версий
   

О том как написать Хеллоу Ворлд в интернете полным полно, так что я решил рассказать о более интересных вещах. Официальное приложение Twitter для Android использует паттерны и возможности графического интерфейса появившиеся в последних версиях sdk, такие как Dashboard, Search Bar, QuickAction и Action Bar. Диалог QuickAction является одной из самых интересных новинок, он отображает контекстное действия для данного элемента ListView. Этот диалог используется также в приложении контактов, начиная с версии 2.0

На написание данной заметки натолкнула одна интересная статья “Anchoring effect”. Однако это совсем не перевод, так как в тексте встречается много лишней информации и исследований в духе «Британские ученые доказали…» Это скорее творческая интерпретация.

В статье описывается один очень важный психологический эффект – эффект якоря или эффект привязки.

В чём секрет?

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

Чтобы что-то оценить, нам необходима отправная точка, некий якорь – что-то вроде «розовой обезьяны».

Например, если спросить – сколько человек составляет население Венесуэлы, что вы скажете? Растеряетесь и задумаетесь. А если задать вопрос: «Население Венесуэлы больше или меньше 65 млн?». Вопрос приобретает иной окрас, и ваш мозг подсознательно начинает опираться на упомянутую цифру, даже если она взята «с потолка». Какой ответ вы дали в первом и втором случае? Во втором случае названное число будет намного больше, чем в ответ на первый вариант вопроса.
А между тем – в Венесуэле живет всего 28 млн человек.

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

Как разработчик, вы сидите на золотой жиле. Вы осознаете это?

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

Подумайте о крупнейших сайтах, которые вы постоянно посещаете: Facebook, Twitter, Flickr, Foursquare, или даже Google — все они были созданы разработчиками, у которых была лишь идея. Было ли это легко? Черт, нет. Но это могло быть сделано только в наше время. Так, черт побери, почему вы просиживаете день за днем, работая на кого-то?

Будучи программистом я многое узнал о том, как создаётся программное обеспечение. Вот несколько фактов, которые могут вас удивить.

Данная статья является переводом статьи Мэтта Эсея «Open source's ardent admirers take but don't give. Free riders' self-defeating logic», опубликованной 13 августа 2010 года в The Register.

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

Спросите, к примеру, команду ИТ-директоров, как это недавно сделала Accenture: почему они столь ревностно внедряют ПО с открытым исходным кодом — а внедряют они его действительно ревностно, поскольку:

• 50% опрошенных «полностью преданны» открытому ПО;
• 69% планируют увеличить инвестиции в него;
• 38% вообще планируют перевести всё критичное для своего бизнеса ПО на открытые альтернативы уже в 2010 году.

И что же вы услышите в ответ?

Привет Хабр!

Меня зовут Алексей Чурбанов из компании «Медиа Лабз».

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

Достаточно давно мы поставили перед собой цель: сделать работу пользователя с компьютером более быстрой, удобной и приятной. Цель глобальная и интересная. Разбили на задачи и проекты — первым проектом среди них был мультибар.

Как ни странно звучит, но речь действительно пойдёт про usability кабинки туалета.

Цель статьи — немного размять мозги.

Сейчас многие говорят про usability. Но не многие всерьёз о нём задумываются.

— Сделаю-ка я высовывающуюсь панельку на своём сайте. Ведь это же… как его… юзабельно!

Но сейчас я хочу поговорить не про веб-интерфейсы и вообще не про интерфейсы, а про устройство кабинки туалета.