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

Для таких людей я перевёл новую статью Тома Демарко, одного из основоположников инжиниринга ПО, разработчика метрик для ПО и соавтора известной книги «Человеческий фактор: успешные проекты и команды».
Эта статья сильно провокационная и сейчас широко обсуждается в англоязычных блогах и странно, что я еще не встречал ее переводов на русский. Но, несмотря на провокационность, в ней есть несколько очень правильных идей, которые могут изменить у кого-то представление о важности и возможности контроля за разработкой.
В общем, читайте перевод статьи под катом.

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

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

Не простое это дело — собственный бизнес :)

Что может быть лучше, чем описание девяти классных фишек App Engine? Разумеется, описание десяти. Участвуя в обсуждениях в группах, мы заметили, что некоторые возможности App Engine часто остаются незамеченными, так что мы выбрали чуть меньше, чем одиннадцать интересных фактов, которые, возможно, просто позволят вам писать программы по другому. Но довольно слов, смотрим первую фишку:

Мы с участниками социальной сети open-life.org решили сделать перевод статьи Джо Шилдза (Jo Shields) «Here we go again – why Mono doesn’t suck». В результате получилась статья «Почему Mono хорош». Копию данного перевода можно прочитать здесь: Почему Mono хорош — open-life.org

Прим.: Если кто захочет инвайт на open-life.org — стучитесь в личку

Я участник Debian Mono Group, Debian CLI Applications Team, и Debian CLI Libraries Team. И уже в течении года работаю над сопровождением пакетов проекта Mono и программ, которые используют его в ОС Ubuntu (и Debian). Мне хорошо известны горячие споры, угрозы и последующие переходы на личности, и сейчас я принимаю ваш «вызов». В этой статье я говорю от себя лично — не от проекта Debian, не от Ubuntu, не от Mono, и не потому, что меня попросил мой начальник.

Вам хотелось «объективного пояснения, чем хорош Mono, почему он не представляет угрозы и почему его следует включить в Ubuntu по умолчанию»? — Я отвечу на эти 3 вопроса по очереди, затем предложу общий вывод к этой статье, а так же к более широкому движению «Анти-Mono». Это сообщение подписано GPG (прим. переводчика: GPG=GNU Privacy Guard — свободная альтернатива набору криптографического ПО PGP) для подтверждения факта его публикации без изменений. Оригинальный текст доступен по адресу retro.apebox.org/herewegoagain.txt чтобы каждый желающий мог проверить его подлинность самостоятельно.

Привет, хабрачеловек. Сегодня я расскажу тебе про некоторые фундаментальные вещи в computer science: частичные вычисления, три проекции Футамуры и суперкомпиляцию.
 
 

1. Сразу к коду

-- функция, которая возводит x в степень y (неотрицательную)
power x y =
    case y of
        0 → 1
        1 → x
        _ → x * (power x (y - 1))


Довольно много написано о мотивации программистов, и как-то маловато информации о мотивации менеджеров. Итак, тезис: в IT-аутсорсе отсутствует мотивация менеджеров проектов. Вообще.

UPD: Перенес в Менеджмент проектов. Спасибо за карму!

Cocotron — это реализация runtime для Objective-C, похожего на рантайм Apple — Cocoa. Он достаточно сильно отличается от другого популярного открытого рантайма — GNUstep, как в целях, так и в реализации.

Cocotron отлично подходит для портирования кода с платформы OSX на Win32. Конечно реализация API далека до идеала, но, как показывает практика, разработчики всегда быстро решают проблемы.

Изначально Cocotron использовался только при кросс-сборке на базе XCode и mingw-toolchain. При кросс-сборке доступно развертывание на Windows, Linux и Solaris.

Конечно такой подход оставлял в цепочке разработки самый сложный и дорогой этап — OSX (оптимально — на оригинальном железе). Возможность Cocotron, как платформы, не могла быть полностью раскрыта из-за этой зависимости.

1 Введение

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

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

Намедни возникла задача внедрения PayPal на коммерческий сайт, работающий под ASP.NET. После детального изучения данного вопроса, выяснилось, что в рунете инфы по нему очень мало. Посему думаю, что будет уместно осветить данный вопрос. Начнем, как всегда, с постановки задачи.

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

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

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

Всем привет! Это моя первая статья в Хабре. Столкнувшись сегодня в ленте на описание Java-фреймворков Spring и Tapestry, решил просмотреть Хабру и найти ценителей «конкурирующих» фреймворков от Microsoft – в частности Composite UI Application Block (CAB) и Unity. К моему удивлению, ничего не нашел. Увидев в коментах в статье про Java-фреймворки просьбу описать механизм инъекций зависимостей, решил начать свой цикл статей про .Net-фреймворки именно с разъяснения вопросов IoC. Итак, встречайте – краеугольный камень (в прошлом) замечательного движка CAB – Microsoft Object Builder.

Всем привет! Хабраюзер shai_xylyd написал статью про аспекты тестирования, где им были рассмотрены некоторые понятия и ценности TDD. В частности, он упомянул очень интересный способ создания первичных юнит-тестов — когда функциональный код пишется совместно с кодом юнит-теста, чем меня очень заинтриговал.

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

Перевод материала Мартина Фаулера. В статье обсуждается общий подход к архитектуре UI и приводятся подробные описания таких шаблонов проектирования, как MVC, MVP, Presentation Model, Forms and Controls, Humble View, Passive View. Статья неплохо прочищает мозг. Для того, чтобы не упустить ни единого нюанса, решил заняться переводом.

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

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

Всем привет еще раз. Это опять я. Внутри хабраката перевод еще одного параграфа статьи Мартина Фаулера.

На этот раз затронута тема MVC. Фаулер весьма популярно про него написал. Я постарался популярно перевести:) Теперь можно понять, почему все носятся с MVC, как с писанной торбой. И, кстати, Фаулер прав — очень много где и много кто воспринимают MVC по-своему. Сам Фаулер пишет про оригинальный MVC, который работал на платформе Smalltalk. Очень познавательно.

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

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

Часть третья. Для минимизации количества отсебятины, текст переводится очень близко по смыслу, вследствие чего перевод приобретает «рубленные» черты. Тем, кто решил прочитать, следует читать осторожно, ибо прочитанное может нанести вред внутреннему чувству эстетики.

Предыдущая часть здесь. Оригинал статьи — здесь.

Предыдущая часть здесь. Оригинал статьи здесь.

Предыдущая часть здесь. Оригинал статьи здесь.

Это последняя часть.

Введение

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

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

Не судите строго, это моя первая статья

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