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

Пару слов вкратце о системе: для чего она предназначена. Чтобы было сразу понятно, что это такое, представьте web-интерфейс для почты, но это не совсем почта, точнее, совсем не почта. Данная система предназначена для обмена документами. Основные документы – это счета-фактуры и накладные. При этом электронные документы являются юридически значимыми, имеют такую же силу, как и бумажные документы с печатями и подписями.

Когда-то я начинал работать, и меня вполне устраивала моя производительность. Но после, когда начались проблемы, связанные с потерянными клиентами, сбежавшими партнёрами, играющими в молчанку поставщиками из-за забывчивости, необязательности, или несвоевременного выполнения дел, у меня возникло желание что-то поменять в своём отношении к работе.

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

Всё нижеприведённое справедливо для меня, директора небольшой минской аутсорсинговой компании, но и вполне может оказаться применимо для широкого круга лиц: менеджеров, админов, кодеров, верстальщиков, дизайнеров, да кого угодно.

Вот так хабрасообщество смотрит на инвестиции в отечественные проекты

Я уже несколько раз писал про разработанные нами в рамках российского права механизмы краудинвестирования, позволяющие быстро вложить небольшую сумму (например, 1000 рублей) в проект. В прошлом топике про механику реализации микроинвестиций разгорелся довольно объёмный спор про то, что в России это не сработает из-за менталитета «все хотят всех кинуть».

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

Осенью 2008 года мы потратили две-три недели свободного от основной работы времени, чтобы написать маленькую утилитку для бэкапа баз данных (MS SQL Server и потом MySQL). Сегодня она приносит нам около $230 000 в год и можно с уверенностью говорить, что суммарно мы заработаем на ней больше $1 000 000.

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

На дворе наступал Новый год, а из головы никак не выходила мысль, что XAML может быть лучше. И, чтобы ему быть лучше, ему нужно перестать быть. Так родилась затея написать альтернативу кошмарному и ужасному XAML'ю: без <Setter.Value>, без {Binding Path=Name, RelativeSource={RelativeSource AncestorType={x:Type Button}}, Converter={StaticResource Converter}}, без FirstValueEqualsToSecondValueOrThirdValueEqualsNullConverter, без <Grid.ColumnDefinitions> <ColumnDefinition/> <ColumnDefinition/> <ColumnDefinition/> <ColumnDefinition/> </Grid.ColumnDefinitions>, без <MultiDataTrigger> <MultiDataTrigger.Triggers> <DataTrigger> <DataTrigger.Binding> <MultiDataBinding>..., без xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml", без всего этого барахла, от написания которого в десятый раз возникают позывы нежно погладить компьютер табуретом и вспоминаются далёкие индусские родственники разработчиков WPF.

Всем привет.
В этой своеобразной статье я хотел бы осветить вопрос эффективности труда в течение рабочего дня на позиции руководителя проектов (другого управленческого звена в IT).
Здесь не будет никакой аналитики в цифрах, выдержек из кучи книг по time managment'у, а лишь личный опыт и сухие выводы. Я не собираюсь изобретать велосипед на Ваших глазах, но надеюсь, что послужу неплохим примером.

Добро пожаловать под кат.

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

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

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

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

Обычно, первое, что человек делает, встретив плохой код — ищет виноватого. Это сразу становится личной или племенной вендеттой:

«Как можно быть таким идиотом?»
«Кто виноват в том, что мой мозг взорвался от всей этой бессвязности и богохульства?»
«Кто оскорбляет <Название Компании>!?»

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

Капитан очевидность рассказал нам, что пользовательский интерфейс — неотъемлемая часть любого программного и технического продукта. Поскольку интерфейс — это все то, через что пользователь может взаимодействовать с такими системами, то логично сделать вывод, что интерфейс есть некоторая передаточная система между желаниями (и проблемами) пользователя и возможностями продукта. И разумно предположить, что эта система, мягко говоря, не обладает 100-процентным КПД.
Получается, что интерфейс — это зло, ведь по сути дела это та помеха (хоть и необходимая), которая мешает нам использовать программный продукт по полной и чинит нам препятствия на пути к достижению наших целей. Уверен, многие из читателей Хабра однажды приходили к такому (на первый взгляд вполне разумному выводу). Давайте теперь поподробнее рассмотрим все за и против и выясним есть ли все-таки в интерфейсах что-то доброе.


Картинка для привлечения внимания.

При изучении любого незнакомого дела, особенно когда речь идет о микроконтроллерах, возникает вопрос — «С чего начать». Ведутся поиски статей по ключевым словам «Getting Started», неизбежно появляется дилема выбора среды разработки и программатора-отладчика. Чтобы помочь вам определиться с ответами на возникшие вопросы, я поделюсь своим опытом в освоении 32-битных контроллеров семейства STM32F от ST Microelectronics.

Выбор контроллера

Вариантов по сути дела было два — STM32F или NXP (LPC1xxx). На микроконтроллеры STM32F мой выбор пал по нескольким причинам.

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



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

По работе столкнулся с программированием контроллера AT91SA7A3, для этого используется IAR. Но поскольку держать вторую систему мне лень, была принята попытка обеспечить возможность программирования, отладки и прошивки под любимой Ubuntu. И вот, после двух недель общения со стенкой посредством обсценной лексики(аж обои начинали шевелиться), таки удалось всё это хозяйство настроить. А поскольку, возможно, я не один такой буду, напишу как это делается.

Что такое хороший язык программирования? Какими качествами и характеристиками он должен обладать? Ответ дать сложно. Вот одно из возможных определений: хороший ЯП должен хорошо решать возложенные на него задачи. Ведь ЯП — лишь инструмент в руках программиста. А инструмент обязан помогать нам в работе. В конце концов, это же и есть причина его создания. Разные ЯП стараются решать разные проблемы (с переменным успехом). Цель, которая ставилась при проектировании Clojure — сделать написанные нами программы простыми. И, как следствие, ускорить их создание, тестирование. А главное, уменьшить время на их понимание, изменение и сопровождение.

Большинство людей, занимающихся или интересующихся разработкой электронных устройств под управлением ARM-процессоров, прекрасно осведомлены о проекте Raspberry Pi. По сути, это первая дешевая development board с открытой архитектурой, хорошей технической поддержкой, а также с большим и дружелюбным сообществом энтузиастов.
Наша небольшая компания (start-up) почти что случайно решила посоревноваться с этой замечательной ягодой. Ну а написать про это я решил после того, как обнаружил интерес к данной теме вот здесь.

«Что? Стивен Кинг „Как писать программный код“ ?! Нет такой книги! Да он вообще не программист ни разу!».
Да, так и есть. Тем не менее — книга с таким содержанием у него есть. Хотя он и не думал, что пишет её об этом. Хотя в результате написал. Хотя, наверное, и не знает об этом. О чём же я тут рассуждаю? О недавно прочитанной мною прекрасной книге «Как писать книги» (англ. — «On Writing»).

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

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

Переговоры №1. Виноторговая компания.

Сначала в переговорной один человек от компании. Непосредственно тот, кто нас пригласил.
Выдержки из диалога:
«Я правильно понимаю, что ключевая тема переговоров – запасы?» — спрашиваю я.
— Да. Мы уже давно этим вопросом занимаемся и вот ищем решение. Мы слышали о решении компании X (не буду называть в этом посте), там очень красиво сглаживаются пики, все планируется. Они уже год применяют эту систему. Очень хорошая, эффективная система.
— Как изменились запасы этой компании за последний год?
— эээ, я не знаю. А зачем вам?
— Почему тогда вы говорите, что система эффективна? Мне кажется, что эффективность какой-либо системы управления запасами надо оценивать не по тому, как она сглаживает пики, а по тому, как изменились запасы. Если они снизились на сумму, превышающую инвестиции в эту систему, и при этом не пострадал объем продаж и удовлетворение спроса, то да, система эффективна. Все остальное – игра цифр и красивых графиков.
— Хм, интересно. Сейчас к нам в переговорную придут люди, вы не говорите им, что снижение запасов – это главный критерий работы такой системы. Низкие запасы – это не всегда хорошо.
— Не понял. А что, какие-то другие есть критерии эффективности? И насчет низких запасов можно поподробнее?
— Ну, вот если, например, ваши запасы вырастут, то банки вам с большим удовольствием будут давать кредиты.
Я вздыхаю. Это говорит, не какой-то студент на интернет-форуме, а человек из бизнеса. Слава Богу, что IT-директор. Уфффф, я с облегчением вздыхаю, что это не директор по логистике.

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

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

Вы верите в бога «ИТ-систему под все бизнес-процессы»? — так начинается заражение идеей. Предупреждаю, в этой статьей будут факты, которые могут повредить вашу картину мира… безвозвратно.
Наверное многие скажут, что — нет! Нет такой! ИТ-ландшафт организации будет всегда состоять из зоопарка различных ИТ-систем!
И я с этим соглашусь.
Но знаете ли вы, что примерно 2000 лет назад — такая ИТ уже была изобретена… Имя ей — бумага.
Бумага — основной, удобный и самый популярный носитель информации за всю историю человечества.

Это ИТ! Кто не верит? Открываем словарь русского языка и читаем:
— технология = наука о технике
— техника = все то что изобретено человеком и не существовало до него в природе
— информационная техника = все то что создано человеком для работы с информацией
— ИТ = наука создания и развития информационных техник.

Бумага существовала в природе? Нет! Значит — техника. Она создана для работы с информацией? Да — текстовой и визуальной. Она появилась в результате научных изысканий? Да! От сюда: бумага = ИТ.

Да, я понимаю что это тяжело осозновать, но я же обещал вам пошатать картину мира! Так что без обид! Если дыхание участилось лучше прекратить читать прямо с этой строки! Я предупредил!

Есть ли ИТ, которая может бросить вызов бумажке? Неужели за 2000 лет не нашлось смельчака? Ответ под катом…

Данная заметка является ответом на недавний пост Joshua.
Вначале планировался отдельный коммент, но в итоге я понял, что он слишком большой.
Я проработал более 6 лет в компании, которая занимается разработкой и внедрением PDM-системы собственного изготовления. Это несколько другой класс систем для других целей, но смысл и грабли те же самые: имеем крупную корпоративную систему, которая позволяет автоматизировать/информатизировать что-то. Я сам вначале очень поражался тому факту, который был озвучен в статье и целиком и полностью, а именно:

• Вы присоединились к новому стартапу.
• Вы мегаталантливое создание.
• Вы можете работать 60, 70, 80 часов в неделю для достижения результата.
• Вы офигенный разработчик и дизайнер.
• Вы не попадетесь в ловушки, в которые попадались другие.
• Вы убедитесь, что в этот раз все будет по-другому.
• Вы настолько хороши, что правила вам ни к чему.
• Вы в жопе.