Сегодня мы предлагаем вашему вниманию отрывок из книги Сергея Тарасова «Дефрагментация мозга. Софтостроение изнутри», которая готовится к выходу в нашем издательстве.

Сокрытие базы данных или как скрестить ёжа с ужом

Упомянув один из крупнейших столпов современного софтостроения — мир ООП, нельзя обойти вниманием и другой — мир реляционных баз данных. Я намеренно вставил прилагательное «реляционные» применительно ко всем основным СУБД, хотя ещё в 1970-х годах такое обобщение было бы неправомерным.

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

Как театр начинается с вешалки, так программирование микроконтроллеров начинается с выбора хорошего программатора. Так как начинаю осваивать микроконтроллеры фирмы ATMEL, то досконально пришлось ознакомится с тем что предлагают производители. Предлагают они много всего интересного и вкусного, только совсем по заоблачным ценам. К примеру, платка с одним двадцатиногим микроконтроллером с парой резисторов и диодов в качестве обвязки, стоит как «самолет». Поэтому остро встал вопрос о самостоятельной сборке программатора. После долгого изучения наработок радиолюбителей со стажем, было решено собрать хорошо зарекомендовавший себя программатор USBASP, мозгом которого служит микроконтроллер Atmega8 (так же есть варианты прошивки под atmega88 и atmega48). Минимальная обвязка микроконтроллера позволяет собрать достаточно миниатюрный программатор, который всегда можно взять с собой, как флэшку.

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

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

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

Доброго времени суток. Предлагаю вашему вниманию вторую статью из цикла о Low Level Smalltalk (LLST). Кто не в курсе о чем идет речь, тем рекомендую прочитать предыдущую, обзорную статью, где рассказывается о том, что такое llst и зачем он был создан.

В этой части мы сконцентрируемся на самом языке Smalltalk, его синтаксисе и «правилах игры».

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

Я давний подписчик блога «GTD» (уст. Учись работать).

С 2008 года я активно читал статьи на Хабре и в Интернете и пробовал:
— вставать в 5:00 утра
— делать зарядку
— обливаться холодной водой
— бегать по утрам
— питаться правильно (особенно зачитывался вегетарианством)
— вести свои делало системе GTD (Things установлен на всех гаджетах :)
— выключать компьютер вовремя (хотя бы до 23:00)
— ну и конечно, сделать 100 отжиманий и кубики на животе…

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

Что изменилось в январе 2012 года?

Рано… в начале кратко обо мне:
— Возраст: 26 лет;
— Семейное положение: женат (с февраля 2012), детей пока нет;
— живем отдельно в Санкт-Петербурге.
— Работаю в офисе 5 дней в неделю с 8:30 до 17:30.
— Иногда задерживаюсь, но не часто.

Если Вы считаете, что опыт Вам не подойдет… Ваше право, но мы же понимаем, что оправдания всегда можно придумать? Я их придумывал лет 5. Я знаю о чем говорю.

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

Начну с того, что ранее широко распространенные интерфейсы как COM, LPT, MIDI в настоящее время морально устарели, но ещё нередко присутствует на современных компьютерах и используется в промышленном и узкоспециализированном оборудовании. Так что для связи какой нибудь собственной железки с компьютером давно уже пора осваивать что-то другое. Как вариант ещё можно использовать всякие конверторы/переходники/эмуляторы, но они не всегда работают как оригинальный интерфейс, порождая массу проблем.

Всё хватит пустой болтовни, приступим к делу. Как использовать USB в собственных устройствах?

Все чаще приходится слышать: "Работай на результат!"

"Работай на результат!" — кричит начальник подчиненному, чтобы заставить этого тупого неповоротливого кретина, принятого в команду по протекции, приносить хоть какую-то пользу общему делу.

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

"Обязательна ориентированность на результат!" — напишет пожилая кадровичка «ГорАвиаВагонМорСтроя» в требования к кандидату на должность помощника бухгалтера, будучи уверенной в том, что раз все так пишут, то и ей надо.

"Наш девиз — Работа на Результат!" — именно так, с двумя Большими Буквами для большего пафоса пишет на корпоративном сайте очередной говноконторы-однодневки молоденькая девочка-всё-в-одном, гордо именующая себя помощником руководителя по связям с общественностью. И этот самый руководитель, даже не знающий, что секретутка это, оказывается, ни больше ни меньше, целый его помощник, тоже употребит эту фразу на фуршете в городской администрации с целью создать себе рекламу в среде местных бюрократов.

Культ карго. Мало кто из произносящих эту фразу может внятно объяснить, какой смысл в неё вкладывается. Люди верят в неё, как в волшебную формулу, заклинание, они пихают её куда ни попадя, надеясь, что она придаст им уникальность, выделит их из толпы таких же неудачников. Организации, Компании, конторы да и откровенные «шараги» не мыслят себя без этого лозунга. Как же это, «Рога и копыта» работают на результат, а мы, что, хуже?



А хуже ли?

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

Источники информации — ограниченная документация доступная на сайте разработчика, и ответы сотрудников компании на вопросы.

Или как получить разработанную плату, не вставая из-за компьютера и не используя химикатов, утюга или ультрафиолета.

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

Многие начинающие радиолюбители не заказывают платы на заводе, а изготавливают их дома. В случае если задача состоит в том, чтобы сделать одну единственную плату, то это решение оправданно, а если нужно сделать 5, 10, 20 плат? Или же Вы не можете заняться процессом травления из-за того, что Ваша вторая половинка не разрешает вам устраивать дома лабораторию в миниатюре? Или Вашей платой \ устройством кто-то заинтересовался, и Вы желаете её продать? — ведь намного красивее и более солидно выглядит плата, сделанная на заводе — с маской и шелкографией.

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

Всем привет! С прошедшим концом света и с наступающими праздниками :)
В качестве подарка сообществу Open Source, а так же любителям антиквариата, мы (совместно с товарищем humbug) решили выложить нашу последнюю исследовательскую разработку.

Предлагаем вашему вниманию с нуля переписанную на C++ реализацию виртуальной машины, совместимую с Little Smalltalk. На данный момент написан код виртуальной машины и реализованы базовые примитивы. Humbug написал серию простых тестов, которые, тем не менее, помогли обнаружить проблемы и в оригинальной версии VM. Реализация бинарно совместима с образами оригинального LST пятой версии.

Месяц работы, 300+ коммитов. А что получилось в итоге, можно узнать под катом.

Доброго времени суток.
В этой статье я хочу сделать обзор одного из главных нововведений в Visual Studio 2010, а именно — функционального языка программирования F#.

Рассматривать синтаксис и потенциал F# мы будем на примере создания своего собственного интерпретатора для придуманного нами языка программирования (Ведь рассказвать о чем-то всегда интереснее на примерах).

Вы когда-нибудь задумывались, как устроены вещи, какой путь они проходят от идеи до реализации, насколько просты простые вещи? Насколько просто сделать расческу? А компьютерную мышь? А деревянную компьютерную мышь из цельного бруска красного дерева с ЖК экранчиком, с собственной электронной начинкой и изготовленным и оплетенным специально для нее кабелем? Думаю, вам будет интересен мой путь, который я прошел за 2,5 года создания моей мышки.

Нет, я не раскрою вам загадку, скрывающуюся в названии MCp0411100101, но постараюсь развёрнуто ответить на комментарий nerudo, записанный в топике Процессоры «Мультиклет» стали доступнее:

Читая описание архитектурных новшевств этого мультиклета, мне хочется воспользоваться фразой из соседнего топика: «Я не понимаю».

Если кратко, то MCp — это потоковый (от dataflow) процессор с оригинальной EPIC-архитектурой. EPIC — это Explicitly Parallel Instruction Computing, вычисления с явным параллелизмом инструкций. Я применяю этот термин здесь именно в этом смысле, как аббревиатуру, а не как ссылку на архитектуру Itanium-ов. Явный параллелизм в MCp совсем другого рода.

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

В мире разработки программных продуктов бытует немало мифов и заблуждений. Чтобы двигаться вперед, а не топтаться на месте, их совершенно необходимо разрушить. Сегодня об одном из самых закоренелых заблуждений, которое к тому же достаточно вредное — называется «Миф об обязательном поле».

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

1. Все необходимые с точки зрения предмета поля (например, ФИО и дата рождения человека, если речь о паспортном столе);
2. Все необходимые для функционирования системы поля (те, без которых не будут работать алгоритмы — например, дата, с которой начинается предоставление услуг, чтобы делать по ним начисления);
3. Важные поля — такие, которые не необходимо, но желательно заполнить (например, обоснование вносимого изменения) — с той мотивацией, что пусть лучше пользователь попотеет, когда не нужно, чем забудет ввести значение, когда будет нужно.

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

Предположим, это ваша цепочка поставок. Сейчас экспертная система будет её оптимизировать.

Вводная: представьте, что вы некая компания, которая производит планшеты и телефоны — майфуны и майпады. Сами вы сидите в Калифорнии, у вас есть несколько своих заводов на Востоке, плюс вы регулярно заказываете кучу всяких комплектующих у тех поставщиков, от которых это выгоднее везти. И ещё у вас есть своя розничная сеть магазинов, где продаются планшеты и телефоны.

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

Есть три проблемы:

• Логистика у нас настолько сложная и разветвлённая, что сейчас над ней работают десятки людей: кто-то занимается распределением майфунов, кто-то раскидывает по магазинам обложки, а производственники просчитывают оптимальные пути сбора комплектующих на заводах со всего мира.
• При этом хочется сэкономить на логистической схеме: вы подозреваете, что умный анализ всех потоков позволит принять решения, например, о месте открытия нового производства или организации дополнительного склада, что в итоге даст вам выгоду.
• И при этом ваши люди постоянно ошибаются с отправлениями – а хочется сделать так, чтобы ничего и нигде не забывалось, всё работало как часы и товары приходили на точки вовремя. Это тоже экономия, но уже за счёт своевременности поставок и отсутствия ошибок.

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

В результате стандартный консервативный аллокатор выстраивает все запросы в очередь на pthread_mutex / critical section. И наш многоядерный процессор медленно и печально едет на первой передаче.

И что с этим делать? Познакомимся поближе с деталями реализации метода Scalable Lock-Free Dynamic Memory Allocation. Maged M. Michael. IBM Thomas J. Watson Research Center.

Самый простой код что я сумел найти — написан под LGPL камрадами Scott Schneider и Christos Antonopoulos. Его и рассмотрим.

Ключевые слова async и await, введённые в C# 5.0, значительно упрощают асинхронное программирование. Они также скрывают за собой некоторые сложности, которые, если вы потеряете бдительность, могут добавить проблем в ваш код. Описанные ниже практики пригодятся вам, если вы создаёте асинхронный код для .NET приложений.

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

Этим летом appplemac опубликовал статью, посвященную изучению ассемблера MIPS. В ней, в частности, была рассмотрена команда syscall, генерирующая системный вызов. Автор сосредоточился на объяснении ассемблера MIPS, и на мой взгляд, недостаточно подробно рассказал, что же это такое — системный вызов. Я в тот момент занимался переносом проекта под архитектуру MIPS, разбирался с прерываниями, исключениями и системными вызовами.

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