Ответ на статью.

Если вы не разрабатываете ПО для машин или систем автоматического поддержания жизни и тд — нижесказанное работает для вас при грамотном применении.

Сразу скажу — не моя идея, в статье «Проектирования больше нет?» сам Мартин Фаулер писал об эволюционном рефакторинге. А Боб Мартин даже целую книгу запилил с примером поэтапного развития приложения (и не одним), назвав «Быстрая разработка ПО» и продемонстрировав умение виртуозно материться на Java и C++.

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

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

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

Вчера я был на мероприятии, одно только посещение которого эквивалентно получению двух высших образований — на финале первого Российского кубка по программированию, Russian Code Cup.

Моя недавняя эпопея со стиральной машиной напомнила мне, почему одна из самых страшных и ненавидимых задач в разработке ПО начинается с вопроса:

«Сколько времени вам на это потребуется?»

Привычность этого бытового прибора внушила мне ложное чувство безопасности

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

На прошлой неделе я рассказал, как устроена активация Яндекс.Станции через звук. Оказалось, что пароль от WiFi передаётся в открытом виде. Я размышлял, зачем вообще нужно было делать активацию так, а не каким-то отлаженным способом.

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



Под катом я расскажу, как сделан прототип, и дам ссылку на демку. Вы сможете сами послушать, как звучит любое сообщение :)

Эпизод с основанием Microsoft – один из наиболее известных в компьютерной истории. В 1975 году Пол Аллен вылетел в Альбукерк, чтобы продемонстрировать интерпретатор BASIC, которые они с Биллом Гейтсом написали для микрокомпьютера Altair. Поскольку у них не было работающего компьютера Altair, они проверили свой интерпретатор при помощи написанного ими эмулятора, выполнявшегося на компьютерной системе Гарварда. Эмулятор был основан только на опубликованных спецификациях процессора Intel 8080. Когда Аллен, наконец, запустил интерпретатор на реальном компьютере Altair – перед человеком, который, как они надеялись, купит их ПО – он даже не знал, заработает ли программа. Она заработала. В следующем месяце Аллен и Гейтс официально основали новую компанию.

За более чем сто лет до интерпретатора BASIC Аллена и Гейтса, Ада Лавлейс написала и опубликовала компьютерную программу. Она тоже написала программу для компьютера, о котором знала только по описанию. Но её программа, в отличие от интерпретатора BASIC, никогда не выполнялась, потому что компьютер, для которого она была написана, так и не был построен.

Эта статья также есть на английском.

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

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

Под катом — дюжина приемов в командной строке — из личного опыта.

WebInspector

Мощный инструмент для дебаггинга JavaScript, полноценный инспектор кода для Sublime. Фичи: установка брейкпоинтов прямо в редакторе, показ интерактивной консоли с кликабельными объектами, остановка с показом стек трейса и управление шагами дебаггера. Все это работает на ура! А еще есть Fireplay от Mozilla, который позволяет подключаться к Firefox Developer tools и максимально простой дебаггер JSHint.

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

Давным-давно

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

Самое крутое, классное и волшебное, что было в JS — это то, что никто в больших организациях не хотел с ним иметь дела, оставаясь в своём спокойном мире прекрасно организованных слоёв абстракций из фабрик и волшебных фреймворков инъекций XML.

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

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

Мы достигли расцвета JS

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

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

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

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

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

Именно таким вопросом я задался сегодня утром, придя на работу. Вроде бы все признаки программиста есть: код пишу уже не первый год, за плечами не один проект (как провальные так и успешные), разбираюсь в структурах данных, алгоритмах и их оценке, знаю, как работают сети и сам компьютер вплоть до железного уровня, знаю и использовал скрам, канбан и иже с ними. Честно ходил на конференции послушать, а так же честно выступить. С огоньком в глазах читал лекции студентам и рассказывал каково это быть программистом. Многие из них пошли на работу программистами, самых толковых я забирал себе в команду. Читал тренинги по паттернам, JavaScript и .NET, проводил хакатон, участвовал в хакатоне, и радовался как ребенок от этих самых хакатонов.

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

Я последние четыре года проработал на банки. Один год на Credit Suisse, офшорно из России с командировками в Лондонский офис, и 3 года – на Citigroup, живя в Нью-Йорке. И вот что я вам скажу: IT в банках – это интеллектуальное гетто, со всеми своими минусами и…минусами. Там встречаются очень умные ребята, крутые команды, но их значительно меньше чем в среднем по индустрии, а основная же масса работников – это зомби, производящие очень плохой код и затем костыли и припарки к нему.

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

Зачем?

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

Скидки ветеранам и пенсионерам меня, ясное дело, не интересовали. А вот необычной акцией «поиграй во флеш-игру на нашем сайте и конвертируй набранные очки в скидку» я решил воспользоваться. Подкатом описание процесса.

Вообще идея сперва изумила своей абсурдностью – вроде как считается, что компьютерные игры вредят зрению, и тогда акция похожа на «вычерпай из подвала 10000 вёдер ледяной воды и получи скидку на лечение ревматизма». Сама игра, надо сказать, тоже поразила своей упоротостью – очевидно, что авторы хотели сделать игру без насилия, поэтому легенда гласит: «с помощью технологии LASIK помогите вернуть кротам зрение». Причём, судя по анимации, лечение близорукости производится путём мгновенного испарения пациента.

Ну да ладно, это лирика. На самом деле я сразу попробовал выбить скидку, однако, весь мой геймерский опыт не помог мне с первого раза получить даже 17%. Сыграв несколько раз, я всё же набрал требуемые 17000 очков, но было ясно, что даже 20000 являются недостижимой планкой, не говоря уже о заветных 25000. Проклятые кроты лезут со всех щелей, но быстро прячутся обратно. При этом за «исцеление» крота даётся 100-200 очков, так что пропускать их нельзя. Не знаю, под силу ли это человеку.

Решение пришло в голову сразу же – нужно писать бота, который пройдёт игру за меня! Процесс написания бота на C# подкатом.

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

1. иметь малые накладные расходы по памяти. Большая часть доступной памяти должна использоваться для хранения текста, а не служебной информации;
2. допускать эффективную вставку и удаление в произвольном месте текста.

Удовлетворить эти требования одновременно непросто. Если рассмотреть широкоизвестные структуры данных, такие как массивы, списки, деревья, стеки, очереди, кольцевые буфера — то такой структуры, которая бы позволила эффективно выполнить оба требования, не встречается. В случае массива имеем незначительные накладные расходы по памяти, но операция вставки имеет сложность O(n), где n — размер редактируемого текста. В случае списка сложность вставки и удаления составляет O(1), однако накладные расходы по памяти в несколько раз превышают размер собственно текста. Деревья, кучи, кольцевые буфера, ассоциативные массивы и прочие структуры и вовсе неприменимы для хранения текста в редакторе.

Встречаются гибридные решения, когда текст хранится в наборе массивов, которые, в свою очередь, объединены в список. Казалось бы, такой подход позволяет объединить преимущества массивов и списков (быстрая вставка/удаление при низких накладных расходах по памяти). Однако такое решение сложно в реализации. Также оно приводит к фрагментации памяти.

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

Несмотря на то, что эта структура данных была открыта давно и использовалась в текстовых редакторах на старых ЭВМ в 8-битную эпоху, это тайное знание предков было в значительной мере утеряно и в современных редакторах встречается редко. Попробуйте открыть файл, состоящий из одной строки мегабайт на 10, в Notepad или Far. Вставка и удаление символов будет длиться секундами.

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

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

// 
// Дорогой мейнтейнер:
// 
// Когда ты закончишь «оптимизировать» эту подпрограмму
// и поймешь, насколько большой ошибкой было делать это,
// пожалуйста, увеличь счетчик внизу как предупреждение
// для следующего парня:
// 
// total_hours_wasted_here = 42
//

Это топик-перевод статьи Eller's Algorithm. В ней рассказывается о способе программной генерации лабиринтов. Дальнейшее повествование идет от лица автора.

 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  
|__   |__       __ __|__   |   __|  |  |  |  |
|__   |__   |__|   __ __|   __ __      |     |
|        |  |  |     |  |__      |__|  |  |  |
|__|__|  |  |   __|   __|__   |   __|__|  |__|
|   __|  |     |__ __ __|  |  |__|  |     |  |
|  |  |  |  |__|  |__   |  |   __|__ __|  |  |
|  |__    __    __ __    __|  |   __   |  |  |
|  |  |  |  |      __|  |   __|  |  |__|  |  |
|  |     |     |__   |  |  |  |  |  |__    __|
|  |  |__|__|__ __|  |     |  |  |      __|  |
|__ __|  |  |  |__   |__|   __|     |   __ __|
|   __|  |   __|__      |__   |__|  |__    __|
|  |  |     |  |     |__|  |   __    __|   __|
|   __|  |__ __|__|      __|  |  |     |  |  |
|   __ __   |      __|__|  |__   |  |  |__|  |
|__ __ __|__ __|__ __ __ __ __|__|__|__ __ __|

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

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

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

Казалось бы, какая связь может быть между Фридрихом Энгельсом и языком С++. Я тоже и подумать не мог что такая связь минимальная, микроскопическая, но в нашем огромном мире все-таки существует. Чтобы узнать больше — проследуйте под кат. Но предупреждаю, под катом десяток ссылок на фотографии.