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

Итак, в чём же состоит особенность реализации десктоп приложений на Java и почему они способны быть очень красивыми? А также, откуда родился миф об ущербности (некоторые экзальтированные личности, порой, склонны даже употреблять слово ‘убогость’) Java GUI, читайте ниже. Я постарался не вдаваться в тонкости, не писать никакого кода, да и вообще не использовать никаких специфических для Java мира знаний. Хотелось бы, что бы заметка была понятна людям, далёким от этой технологии.

Большинство эрудированных программистов таки знают, что…

Думаю, общей информации по Inferno уже достаточно, и можно перейти к главному вопросу: что из себя представляет Inferno изнутри, с точки зрения программиста? В чём заключается взаимодействие программиста со средой предоставляемой Inferno? Сколько нюансов поведения и разных видов сущностей должен держать в голове программист в Inferno?

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

По большому счёту мне давным давно пофиг, на каком языке писать (я программирую с 1989 года, и за это время перепробовал кучу языков). Но… всё таки на одних языках работать приятнее, чем на других — и здесь дело не в том, что одни языки лучше других, а в том, что для разных стилей мышления лучше подходят разные языки.

Переход от Perl к Limbo — очень контрастный. Языки совершенно разные: Perl — не типизированный вообще, Limbo — сильно типизированный; в Perl нет нормальной поддержки нитей и асинхронности приходится добиваться через мультиплексирование, Limbo — чуть ли не вынуждает писать именно многопоточные программы (если вы смотрели презентацию Роба Пайка, то там был прикольный пример с многопоточным поиском простых чисел); etc. И, тем не менее, Limbo мне очень понравился и писать работающий код я на нём начал практически сразу.

Я уже не очень хорошо помню C, но попробую описать Limbo именно в плане отличий от C — думаю, так будет проще для большей части аудитории (и ни слова про PHP! :)).

Один из краеугольных камней архитектуры Inferno — юниксовая идея с файлами-устройствами доведена до предела: в Inferno файлами представлено абсолютно всё. Например, в Inferno нет понятия «сокет».

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

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

Когда не работается, многие читают bash.org.ru или anekdot.ru… а я этой зимой полез от скуки перечитывать сайт OS Inferno. Полез с тоской, потому что хотя меня к Inferno давно тянуло, практической пользы я от чтения доки по Inferno ожидал сколько же, сколько и от вышеупомянутых сайтов.

Но произошло нечто неожиданное — в процессе чтения на меня снизошло озарение: я понял, что OS Inferno это не операционная система, а среда разработки!

Изначально OS Inferno меня заинтересовала лет 5 назад, когда я где-то прочитал фразу «Новая ОС от авторов C и UNIX, результат 30-летних исследований!».

Бретонские Bonnets Rouges жгут порталы контроля системы Ecotaxe. Фото Europe1.fr

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

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

Итак, суть статьи заключается в том, чтобы понять: можно ли в РФ физическому лицу законно получать прибыль от продаж программ в App Store? Просмотр тематических форумов с подобными вопросами привел к выводу: мнения людей на этот счет расходятся. Одни считают, что можно, другие — что такая деятельность будет квалифицироваться как незаконная предпринимательская деятельность, т.к. договор от Apple — это агентский договор и в нем нет ни слова про авторские вознаграждения, и, как следствие, нужно регистрироваться в качестве индивидуального предпринимателя (ИП).

В начале октября мне удалось побывать на конференции Lucene Revolution, которая проходила в городе-герое Бостоне. Эта конференция была посвящена открытым поисковым технологиям Apache Lucene и Apache Solr. Мне кажется, что на хабре в частности и в рунете в целом этим технологиям уделяется незаслуженно мало внимания. Давайте исправим это упущение.

Последнее время на популярно-технических форумах я часто встречаю ожесточённые споры приверженцев и противников .NET. Эти споры, как правило, начинаются из-за недоразумения, и заканчиваются жестким троллингом, беседами “за жизнь” и сравнением радиусов и удельных плотностей материала различных сферических коней. Обе стороны силятся доказать и аргументировать, но ни одна не хочет посмотреть на предмет спора другими глазами. Хабрахабр не исключение, увы.

Накалу страстей такой беседы позавидовали бы религиозные фанатики. Единственное, что спасает противников от крестовых походов друг на друга, вооружившись вилами и LangSpec’ами — то, что они разделены интернетом.

Так жить нельзя, господа. Мне захотелось исправить эту ситуацию, и выступить с одной из сторон. Этим постом я попробую нанести сообществу непоправимую пользу и разобраться с мифами, на обсуждение которых, а не на взаимное членовредительство, к сожалению, и уходят силы спорщиков. А так как я в своё время перелез с C++ на C# и всё вокруг него, то я буду развенчивать негативные мифы, прибавлять позитива и всячески приукрашивать действительность — а как без этого. И — заметьте — это обойдется совершенно бесплатно для M$. Ну а сделать я это хочу в формате Q&A.

В одной старой шутке говорится: если у вас есть проблема, и вы собираетесь решать ее с использованием регулярных выражений, то у вас есть две проблемы. Мне кажется, сверхурочная работа — что-то из той же серии. Я сформулировал бы это так: если у команды есть проблема, и для ее решения планируется работать сверхурочно, то у команды две проблемы. В чем же заключается вторая проблема?

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

Истощение

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

Здравствуйте, многоуважаемые хабрачеловеки!

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



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

Как и многие из вас, мы раскручиваем сайты, причем делаем это исключительно законными способами. Мы считаем это правильным. В этом безумном и нередко жестоком мире важно сохранить лицо. Не ради денег. Ради обыкновенного человеческого достоинства.

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

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

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

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

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

Первоначально необходимо выяснить цель визита и полномочия сотрудников на совершение определённых действий. Данные полномочия могут быть выражены в различных документах (постановлениях начальника органа дознания, суда, следователя, дознавателя) в зависимости от того, каким законом регламентированы их действия (доследственная проверка в рамках ст. 144, 145 Уголовно-процессуального кодекса РФ или деятельность в рамках Законов «О милиции», «Об ОРД»).

Рано или поздно каждому из нас приходится оставлять одну работу и отправляться на поиски другой более перспективной и высокооплачиваемой...
Большинство работодателей ценит в сотрудниках не только конкретные навыки, но и обучаемость — способность «осваивать целину». Поэтому чрезвычайно важно проявить себя грамотным специалистом с самых первых дней на новом рабочем месте. Одним из основополагающих качеств менеджера проектов является способность планировать и не только проектную работу, но и свои активности. Вот план интеграции, который я составил как раз перед переходом на новое место, во время двухнедельной отработки. Как говорится, готовь сани летом :)

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

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

Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.