[Статья Armin Ronacher о принципах вычисления коллизий в сетевых шутерах. Носит скорее обзорный и исследовательский, нежели технический характер. Здесь и далее в квадратных скобках примечание переводчика]

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

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

Вторая часть

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

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

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

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

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

При разработке некоего программно-аппаратного комплекса потребовалось создать клиентское устройство, которое для прочих устройств должно выглядеть как обычная USB-флешка, или если более формально, то USB Mass Storage Device. Необычность устройства в том, что оно должно имитировать для внешнего мира файловую систему FAT с файлами достаточно большого размера (2GB и и более), при том, что сами файлы на устройстве, конечно, отсутствуют и находятся в сети. Да и вообще это не файлы, а некие аудио-потоки.

Задача, на первый взгляд, простая: на каждый запрос на чтение блока (команду SCSI) отдаем содержимое этого блока. Блок может либо принадлежать какому-нибудь из «файлов», либо содержать служебную информацию FAT.

Хабраприветствую всех, кому интересна эта тема.

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

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

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

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

1. Почему стоит начать работать «в белую»
2. Почему на начальном этапе ИП лучше ООО
3. Что делать, если партнёров несколько

Если вы – начинающий или уже опытный фрилансер и подумываете о работе «в белую», но ещё точно не определились с вопросами «Стоит ли оно того?» и «ИП или ООО?», вэлком

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

Честно говоря, написание этого текста преследовало вполне корыстные цели: он является некоторой лакмусовой бумажкой для отправки людям, с которыми предстоит сотрудничать.

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

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

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

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

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

Итак, пришло время раскрыть некоторые карты и рассказать о том, как устроен Tactoom изнутри.

В этой статье я расскажу о разработке и выведении в production веб-сервиса с использованием:
NodeJS (fibers), MongoDB, Redis, ElasticSearch, Capistrano, Rackspace.

Перебрал множество мелочей, а основные проблемы остались. “Хотя, действительно, работал”, — говорит Olegapro.

Чем старше я становлюсь, тем менее важной становится запятая. Пусть читатель сам решает, где ему ставить паузы. — Elizabeth Clarkson Zwart

Примерно так я комментировал свой код двадцать лет назад (внимание, чуток драмы):

/*
 * Когда мы дойдем сюда, наша структура уже будет готова. 
 * К тому же, мы создали достаточно большой буфер, в который 
 * можно засунуть все входные данные, плюс есть немного места
 * про запас. Я не уверен, понадобится ли оно, но хуже не будет. 
 * Теперь нам надо обновить счетчик, предполагая, что клиент 
 * уже прочитал значение, но еще не использовал его. Сначала 
 * я хотел переложить обязанность инкремента на плечи вызывающего
 * кода. С другой стороны, это означает, что инкремент нужно делать всем, 
 * поэтому я решил, что будет лучше перенести его сюда. Но мы можем 
 * пересмотреть это решение позже, если вдруг кому-то из внешних функций 
 * захочется делать инкремент самому.
*/
counter++; // инкрементировать счетчик для потребляемого значения

/*
 * Теперь нужно просмотреть весь буфер с данными. Для этой 
 * операции нам понадобится еще один индекс, иначе перед 
 * выходом из функции мы потеряем начальное значение. 
 * Я хотел назвать эту переменную ‘ref’, потому что в некотором
 * смысле мы будем обращаться с ней как со ссылкой на данные. 
 * В конце концов я пришел к выводу, что самым лучшим  
 * названием для нее будет ‘pos’. Если что, я не против обсудить
 * это решение.
*/
char* pos = buffer; // начинаем наш обход данных

/*
Теперь, мы...
*/

Ну что, узнаете? А должны! Если быть предельно невежливым, весь код выше написал нуб. (Между прочим, если вы не знаете, кто такой нуб, значит вы — нуб).

Мне повезло: я побывал по обе стороны баррикад и теперь знаю, что и как делает заказчик на проектах разного уровня и что делает фрилансер, чтобы получить или провалить такой проект. В итоге я уверен, что 95% фрилансеров говорят с заказчиком на разных языках.

Осторожно, butthurt.

Если вы, вдруг не знали, то помимо всякой ерунды, публикуемой на этом блоге, я еще и занимаюсь переводом блога Эрика Липперта (Eric Lippert) Fabulous Adventures in Coding на русский язык. В русскоязычном варианте этот блог носит название Невероятные приключения в коде.

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

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

В этой статье я хочу поведать о еще одном классе задач, решаемых нейронными сетями – сжатии данных. Алгоритм, описанный в статье, не претендует на использование в реальных боевых условиях по причине существования более эффективных алгоритмов. Сразу оговорюсь, что речь пойдет только о сжатии без потерь.
Большинство источников в Интернете утверждают, что есть 3 основных популярных архитектур нейронных сетей, решающих задачу сжатия данных.

1. Сеть Кохонена и ее вариации. Часто используется для сжатия изображений с потерей качества, не является алгоритмом сжатия без потерь.

2. Ассоциативная память (Сеть Хопфилда, Двунаправленная ассоциативная память и др.). «Сжатие данных» для этого класса сетей является «фичей», побочным явлением, так как главным их предназначением есть восстановление исходного сигнала/образа из зашумленных/поврежденных входных данных. Чаще всего, на вход этих сетей поступает зашумленный образ той же размерности, потому о сжатии данных речь не идет.

3. Метод «Бутылочного горлышка».

О последнем методе и пойдет речь в статье.

Рано или поздно каждый пользователь Линукса задумывается над созданием собственного дистрибутива. Некоторые аргументируют это тем, что можно «все настроить под себя». Другие сетуют на то, что среди уже представленных дистрибутивов в Ветке нет идеального. А у них, якобы, есть суперконцептуальные идеи для собственной системы. Зачем я всю эту психологию затеял? Для того, чтобы сразу перекрыть кислород играющимся с Линуксом новичкам, которым делать нечего. Если уж задумались над созданием ОС, думайте до конца. Итак,

Я хочу создать ОС на базе Linux.
Сразу предупреждаю: был бы XVIII век, всех тех, кто для основы своей будущей системы выбирает другой развитый дистрибутив (и, не дай Бог, популярный...) ждала бы виселица. Пост именно про создание системы с нуля, а значит, всякие Slax и Linux Mint мы трогать не будем.

UPD: Метод, аналогичный использованному здесь включен в поставку NuGet 1.6. Соответственно статья устарела.

Вот что мне всегда нравилось в джаве, так это Maven. Один файл со списком всего нужного, и никаких бинарников в репозитории. Когда появился NuPack, я решил — ура, вот оно, счастье пришло на нашу улицу. Но не тут то было. NuPack представлял удобный интерфейс для работы с пакетами… но без возможности нормально вкрутится в процесс сборки.

Поковырял я его тогда, посмотрел, но так реальной пользы и не увидел. Не больно большая помощь — качать ручными powershell-командами пакеты поименно. Ну да, удобнее, чем скачивать фиг знает откуда, да еще руками references добавлять, но ведь мне это далеко не каждый день нужно. В общем, игра не стоит свеч.

Но в один прекрасный день я понял, что с папкой Shared\Bin в моем сорц-контроле нужно что-то делать, ибо распухла она уже неимоверно. Решил глянуть я, не изменилось ли что-нибудь с NuPack-ом, который уже NuGet-ом стал именоваться? Нет, воз и дальше там.

Но у nuget.exe появилась интересная фича…

Приветствую всех дроидеров в эти непростые для нас времена.
Честно говоря, заколебала эта шумиха о патентах, войнах и т.д., но в данной статье речь пойдет не об этом.
Я не собирался писать статью на данную тему, так как везде всего полно о работе с базой данных в Android и вроде бы все просто, но уж очень надоело получать репорты об ошибках, ошибках специфичных и связанных с БД.
Поэтому, я рассматрю пару моментов с которыми я столкнулся на практике, чтобы предостеречь людей, которым только предстоит с этим разбираться, а дальше жду ваших комментариев на тему решения указанных проблем после чего внесу изменения в пост и мы сделаем отличный туториал, который будет образцом работы с SQLite в Android не только для начинающих, но и для тех, кто уже знаком с основами и написал простые приложения.

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

Когда происходит планирование потоков

Микроядро QNX Neutrino не работает постоянно, а получает управление только в случае системных вызовов, исключений и прерываний. Также микроядро во время своей работы выполняет планирование потоков. Отсюда можно сделать верный вывод, что операция планирования потоков происходит не сама по себе, а по какому-то событию.

Введение

Кажется, монады в программировании стали загадкой века. И для этого есть две причины:

• недостаточное знание теории категорий;
• многие авторы стараюстся не упоминать категории вообще.

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

Мы начнём с простого введения в категории и функторы, затем дадим определение монады, приведём простые примеры монад в категориях и в конце приведём монадическую терминологию используемую в языках программирования.

Я уверен, что монады с точки зрения категорий почти элементарны.

Содержание

1. Категория
2. Функтор
3. Естественное преобразование
4. Монада
5. Монады исключения и состояния
6. Монады в программировании
7. Ссылки