Этот пост – отчет по результатам годового изучения платформы Java EE.
Он будет полезен мне своей отчетностью. Может быть пост будет полезен тем читателям хабра, которые задумали учить Джаву.

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

Обзор и сравнение предложенных хабралюдьми систем

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

Вторая часть длинная (да еще и со скриншотами), если тема не интересна — лучше и не начинить читать :)

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

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

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

Внимание: вся нижеприведенная информация изложена с позиций минимизации затраченного времени (и увеличения надежности мероприятия) и с учетом отсутствия прописки в городе регистрации юр. лица (и отсутствия рабочего офиса).

Продукт и команда

Перед стартом обязательно имейте хотя бы что-нибудь. Что-нибудь, что приносит деньги. Без денежного потока (пусть даже в 10-20 тысяч рублей) затевать все это бессмысленно (далее будет понятно, почему, но первичные расходы на оформление всей волокиты составляют порядка 30к рублей). Естественно, открывать свое юридическое лицо и оформлять бизнес стоит в том случае, если вы собираетесь расти. И не просто расти, а очень сильно расти. Иметь оборот в 20-30 тысяч рублей можно и не имея никакого юридического лица, а при «нелегальном» обороте в районе 100 тысяч уже могут начаться различные проблемы с государством (и красиво оформить это может уже не получиться).

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

Ладно, вроде у нас есть, что продавать (будь это хоть утилита «Time Machine для Windows»). У нас есть пара человек, которые разделяют ответственность за компанию и готовы работать во имя ее успешности. Что дальше?

Дальше самое интересное.

11 правил, следуя которым можно увеличить производительность скрипта, написанного с использованием jQuery.

CodeIgniter предоставляет неплохие возможности по обработке ошибок, но мне они показались недостаточными по следующим причинам:

• отсутствует возможность обработки исключений
• отсутствует возможность уведомлять администратора сайта о возникающих ошибках через почту
• довольно скудная информацию о возникающих ошибках (в фреймворке с которым я работал раньше текст ошибки дополняется дампом глобальных переменных, что очень сильно облегчает процесс отладки, хотелось бы подобную схему увидеть и в CodeIgniter)

Будем это исправлять =)

Данная методика позволяет в течение часа проверить ВСЕ важнейшие параметры качества любого сайта: начиная с вашей домашней страницы и заканчивая крупнейшим порталом. Все пункты универсальны.



Методика ценна именно своей скоростью и универсальностью.

Введение

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

Это не шутка. 90% от числа позвонивших в нашу компанию остаются с нами и пользуются услугами нашей компании как минимум еще один раз. Я решил не мудрить с теорией и изложить основное тезисами. Уверен, кому-нибудь пригодится. Наш бизнес — такси, однако большинство «ноу-хау» применимы совершенно в любом бизнесе.

Представляю вашему вниманию перевод очередного замечательного эссе Пола Грэма What Startups Are Really Like.

Октябрь 2009
(Это эссе основано на выступлении в Школе Стартапов в 2009г.)

Я не знал о чем говорить в Школе Стартапов, поэтому я решил спросить создателей стартапов, которые мы профинансировали. О чем я еще не написал?

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

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

Я с гордостью могу сказать, что получил один ответ, который гласил:

Что больше всего меня удивило, так это то, что все действительно было довольно предсказуемо!

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

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

• Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
• Проектирование структуры программы
• Кодирование (набор программного кода согласно проектной документации)
• Тестирование и отладка
• Внедрение программы
• Сопровождение программы
• Утилизация

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

Продолжим наше обсуждение программирования Magic the Gathering. Сегодня мы обсудим то, как формируется объектная модель конкретной карты. Поскольку карты взаимдействуют со всеми участниками системы (с игроками, другими картами, и т.д.), мы также затронем вопросы реализации базового поведения карт. Как и предже, мы будем использовать экосистему .Net, хотя в будущем (намек) мы увидим использование неуправляемого С++. Также, для примеров мы воспользуемся картами 8^й и поздних редакций.[1]

Предыдущие посты: §1

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

Да, это он в 1998 году продал свою компанию Viaweb интернет-гиганту Yahoo, которая впоследствии назвала этот продукт Yahoo Store. Да, это он основал венчурный фонд Y Combinator. Да, это его журнал BusinessWeek включил в список 25 наиболее влиятельных людей в Сети за 2008.

Хотите читать по-настоящему интересные аналитические статьи? Вам однозначно к Полу. Я настоятельно рекомендую прочитать его заметки. Особенно если вы it-шник. Особенно если вы собираетесь открывать свой бизнес.

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

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

(От перев. Данная статья не претендует на полноту и непротиворечивость, потому мы не будем строить на ее основании никаких теорий. Это всего лишь практическое пособие для разработчиков, немного исправленное и дополненное мной под реалии Рунета.)

Одним из самых странных статистических фактов, связанных с использованием браузеров, является широкая распространенность Internet Explorer версии 6, 7 и 8. На сегодняшний день все версии Internet Explorer вместе занимают примерно 65% рынка используемых в настоящее время браузеров. Среди веб-разработчиков эта цифра ниже, здесь доля пользователей IE составляет лишь 40% рынка.
(От перев. Надеюсь, эти 40% составляют лишь несчастные верстальщики, проверяющие свои сайты на предмет кроссбраузерности. Статистика по Рунету доступна, например, здесь. Заметьте, в сентябре у всех браузеров IE-семьи график без видимых причин подскочил — это вернулись за свои компьютеры офисные пользователи, самые преданные почитатели наших героев.)

Интересно, что популярность браузеров семейства IE примерно одинакова, нельзя выделить один доменирующий браузер, как это было ранее. (От перев. Конечно, нельзя. Вот смотрю и ну никак не могу выделить доминирующий браузер. =) ) Таким образом, сейчас веб-разработчики обязаны проверять работоспособность своего проекта в различных браузерах, разрабатывая как сайты для своих заказчиков, так и персональные странички.

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

Эта статья является попыткой дать исчерпывающую, легкую в восприятии информацию для веб-разработчиков, пытающихся понять различия в обработке CSS между IE6, IE7 и IE8. Здесь собраны краткие описания для свойств, поддерживаемых одним или двумя браузерами, но не всеми тремя сразу. Здесь не рассматриваются свойства, не выполняемые ни одним из IE, а также специфичные только им. Таким образом, акцент стоит именно на различиях между браузерами, а не на недостатке поддержки ими тех или иных CSS-свойств.

Здравствуйте.

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

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

В крупных конторах для этого есть специальные люди, которые занимаются тем, что пишут unit-тесты.

Меньшие конторы, фрилансеры этим грешат, да и на маленьких проектах это не всегда нужно. Согласитесь, если класс на 100 строк, то писать тесты на 200 строк кажется лишней тратой времени.

Тем не менее, не буду вдаваться в подробности кому надо кому нет.

Я хочу показать как можно клево тестировать код на NetBeans с удобным GUI.

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


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

PHP один из самых широко используемых языков для создания вебсайтов. PHP фреймворки, такие как Zend, CakePHP, CodeIgniter и т.д и open source классы и библиотеки упростили разработку.
Независимо от того, являетесь ли вы опытным разработчиком или новичком, инструменты, которые вы используете, имеют прямое влияние на вашу продуктивность. Здесь собран список действительно полезных утилит и расширений для PHP разработчиков, которые помогут ускорить разработку, и улучшит итоговое качество кода.

В этой статье рассматривается настройка continuous integration процесса с метриками кода. Предполагается работа с java кодом и библиотеками: junit, cobertura, findbugs. В качестве системы сборки используем ant, а сам процесс будет управляться из cruise control. В качестве scm будет немного git'а.

Что мы получим в итоге? Ява проект с ant'овским сценарием сборки. Итогом сборки будет откомпилированный проект и набор метрик: отчеты по junit тестам, процент покрытия кода тестами и отчет о потенциальных ошибках. В дополнение, весь процесс сборки будет проходить ежедневно в автоматическом режиме и вся история метрик сохраняется для групповых отчетов.

Здравствуйте. В этой статье я хотел бы написать про один очень интересный способ хранения иерархических структур в базах данных, не относящийся при этом к общепринятым и общеизвестным трём (Adjacency List, Nested Set, Materialized Path). Я не встречал в интернете упоминания о нём, о чём очень удивлен, ведь, по моему мнению, — это лучший и единственный способ хранить иерархические структуры. При разработке console-like форума я воспользовался именно этим способом, о чём ни на грамм не жалею. Это авторская статья и ни одно предложение не было вставлено метотодом копипаста.