К написанию данной статьи меня побудил вопрос на Тостере, связанный с WSL. Я, после нескольких лет использования систем на ядре Linux, около полугода назад перешел к использованию Windows 10 на домашнем ПК. Зависимость от терминала и Linux окружения в моей работе практически сразу привели меня к вопросу: или ставить виртуалку или попробовать WSL. Я выбрал второе, и остался вполне доволен.

Под катом я расскажу как установить и настроить WSL, на какие я наткнулся проблемы и ограничения, как запускать Linux приложения из Windows и наоборот, а так же как интегрировать элементы окружения Xfce в окружение рабочего стола Windows.

От переводчика: Это перевод статьи от одного из разработчиков ASP.NET, в которой подробно рассказывается о механизме управления состоянием страницы — ViewState'е. Несмотря на то, что статья написана в 2006 году, она до сих пор не потеряла своей актуальности.

ViewState — очень непонятное существо. Я попытаюсь положить конец всяческим кривотолкам, и постараюсь объяснить, как на самом деле работает механизм ViewState'а, от начала до конца, посмотрев на него с различных точек зрения.

Есть множество статей, авторы которых пытаются развеять мифы о ViewState'е. Можно даже подумать, что это все — борьба с ветряными мельницами (где ViewState – ветряные мельницы, а Интернет – инструмент борьбы). Но, я вам доложу, мельницы ещё не остановились. Как раз наоборот, они вертятся и заполняют собой вашу гостиную. Пора бы нанести по ним ещё один удар. Не тревожьтесь, при написании этой статьи ни одна ветряная мельница не пострадала.

Приветствую всех. Сегодня расскажу вам как я проходил собеседования в Москве на позицию .Net Developer. Усиленно готовился к собеседованиям месяц, целыми днями сидел и смотрел вопросы и пытался отвечать на них, а также читал книжки по С#. В статье привожу интересные задачки и вопросы, которые мне задавали в разных компаниях в Москве. Заранее скажу, что я попал в ту компанию, в которую хотел. Я прошел 4 собеседования в этой компании и меня наконец то взяли! Много статей было прочитано в частности здесь и надеюсь, что эту статью тоже будут читать начинающие Net разработчики и спрашивать все в комментариях.

Кому интересна тема прохождения собеседований, прошу под кат!

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

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

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


Сцена из Minecraft, до и после добавления нескольких шейдеров.

Задача этого туториала

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

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

Впервые квартово-квинтовый круг был описан в книге «Идея грамматики мусикийской» от 1679 года русско-украинского композитора Николая Дилецкого.

Каждый, кто пользуется командной строкой Linux, встречался со списками полезных советов. Каждый знает, что повседневные дела вполне можно выполнять эффективнее, да только вот одно лишь это знание, не подкреплённое практикой, никому не приносит пользы.

Как выглядят типичные трудовые будни системного администратора, который сидит на Linux? Если абстрагироваться от всего, кроме набираемых на клавиатуре команд, то окажется, что команды эти постоянно повторяются. Всё выходит на уровень автоматизма. И, если даже в работе есть что улучшать, привычка противится новому. Как результат, немало времени уходит на то, чтобы делать так, как привычнее, а не так, как быстрее, и, после небольшого периода привыкания – удобнее. Помнить об этом, сознательно вводить в собственную практику новые полезные мелочи – значит профессионально расти и развиваться, значит – экономить время, которое можно много на что потратить.

Перед вами – небольшой список полезных приёмов работы с командной строкой Linux. С некоторыми из них вы, возможно, уже знакомы, но успели их позабыть. А кое-что вполне может оказаться приятной находкой даже для знатоков. Хочется надеяться, что некоторые из них будут вам полезны и превратятся из «списка» в живые команды, которыми вы будете пользоваться каждый день.

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

Тема моего доклада — то, как мы запускали в продакшн микросервисы на достаточно нагруженном проекте. Это некий агрегированный опыт, но поскольку я работаю в компании «M-Tех», то давайте я пару слов расскажу о том, кто мы.

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.

Детектив по материалам IT. Часть первая

Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».

Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…

И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.

Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.

Статья представляет собой пошаговое описание моего опыта создания кроссплатформенного десктопного приложения с помощью Webix, Electron и Node.js.

Однажды мне пришла в голову светлая мысль создать десктопное приложение на базе стека веб-технологий, который мне хорошо знаком. Знаю, что программисты, пишущие под десктоп, обычно используют C++, Java, C#, а на стек веб-технологий для этих целей смотрят свысока. Но, поскольку я писал приложение для себя, то справедливо решил, что использование знакомых инструментов ускорит процесс. Ну и конечно захотелось «скрестить ужа с ежом» и посмотреть что получится. Если вкратце, то получившийся результат можно запускать и как обычное веб-приложение, и как десктоп.

Код уже готового приложения можно скачать с GitHub.

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

Когда мы имеем дело с финансовой системой на основе блокчейна, то процесс денежного перевода выглядит совершенно иначе. В Bitcoin не существует никакой общей таблицы вида <адрес, баланс>, ровно как и не существует регулятора, который бы эту таблицу редактировал. В этой статье я покажу, что из себя представляет транзакция в Bitcoin, как она строится, и объясню, зачем же внутри Bitcoin добавлен свой язык программирования, про который все слышали, но никто не видел.

Алан Кэй любит ссылаться на себя, и часто начинает свою речь с фразы: «Закон Кэя номер один гласит...». Наверное, он имеет на это право. Много лет его недооценивали, загоняли в рамки и даже гнобили.

Алан Кэй – человек, который не может держать свое мнение при себе, если тема дискуссии действительно волнует его. За это ему и пришлось поплатиться пару раз. Однако ему везло, и в результате он оставался в выигрыше. В его случае справедливо изречение: «Все, что ни делается — все к лучшему».

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

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

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

«Героизм возникает от некомпетентности: герои нужны тогда, когда дело организовано плохо и люди не способны исполнять свои обязанности.»
— Борис Стругацкий



Должен кое в чём признаться — я не рок-звезда программирования. И не хакер. Я не владею ниндзюцу. Никто никогда не называл меня волшебником.

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

Тем не менее, каждую неделю я вижу, как ищут ниндзя-программистов, которые, полагаю, нарезают строки кода с невероятной точностью. Я читаю о технарях рок-звёздах и представляю, что они пишут такие же красивые функции, как соло “Stairway to Heaven”. Я слышу, как люди бросаются словом «хакер» (и связанными с ним «хак», «хакфест» и «хакатон»), как будто рандомно ломать что-то на кусочки или вламываться в несанкционированную систему — хорошо.

И нельзя забывать про этих потрясных волшебников, которые из ничего создают нечто с помощью своей… *магии*

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

Но что, если вы, как и я, не соответствуете этим ярлыкам?

Если вы не разделяете чувства рок-звёзд-ниндзя-хакеров-волшебников, то делаете что-то не так? Не-а.

Дистрибутив операционки крошечный — всего 17 мегабайтов. Его можно быстро скачать и опробовать.

Целевая платформа — x86-64. Маловероятно, что кто-то будет экспериментировать с подобным в качестве реально установленной операционки, поэтому нам понадобится любая виртуальная машина, к примеру, VirtualBox или QEMU. Сам создатель пользуется коммерческой VMware Workstation. Задайте для виртуальной машины как минимум полгигабайта памяти.



Со скачанного образа можно просто загрузиться и работать в режиме LiveCD или установить систему на диск. Установка TempleOS не сложнее, чем установка любой современной операционной системы. Нужно лишь несколько раз нажать на клавишу y и дождаться копирования файлов.

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)

Итак. Если вы не садист или моральный урод, а ваши сотрудники — не мазохисты, то сомневаюсь, что кому-то из вас наказания доставляют удовольствие. Мне — нет.

Учиться, учиться и еще раз учиться!
В.И.Ленин

Основная сложность в работе специалиста IT в том, что IT очень изменчивая область. Если вы не будете постоянно изучать что-то новое, вы рискуете остаться без работы. Закончим с прописными истинами, вы их и без меня знаете. Перейдём к практическим советам. Так как я уже много лет специализируюсь на «тёмной стороне силы» (IT менеджмент), и давно уже не программирую в коммерческих целях (только для души и редко — времени не хватает), то советы будут в основном для ИТ менеджеров (проект менеджеров, тимлидов, тим менеджеров и прочая и прочая братия, жирующая на шее трудяг программеров и сисадминов), но часть навыков пригодится любому IT специалисту.

Итак, что же надо изучать настоящему или будущему IT менеджеру, где изучать и сколько это стоит. Всё сугубое IMHO.

Ты слышал про парня, который попрощался с OOП?

О нет. Ещё один? Что же он сказал?

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

Ох. Да, я слышал всё это раньше...

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

Двигаться дальше к чему?

Ты чего? К следующему технологическому прорыву, конечно!

А, к этому… И что там у нас на очереди?

Еще несколько лет назад отечественное образование в сфере геймдизайна и продюсирования игр было редким зверем. Образование, говорите?

Да, на Западе есть! Шотландский университет Абертэй Данди запустил курсы для разработчиков игр ещё в 1996 году. Канадская школа DigiPen дает полноценное бакалаврское образование по разработке игр. Вообще в 2000ых годах рост рынка видеоигр положительно повлиял на развитие образовательных учреждений, занимающихся обучением разработке игр за рубежом. Обучение проводится на базе Игровой Академии Германии, Академии искусств Сан-Франциско, Дармштадтского университета прикладных наук и многих других.

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

Как известно, в современных архитектурах x86(_64) и ARM виртуальная память процесса линейна и непрерывна, ибо, к счастью, прошли времена char near* и int huge*. Виртуальная память поделена на страницы, типичный размер которых 4 KiB, и по умолчанию они не отображены на физическую память (mapping), так что работать с ними не получится. Чтобы посмотреть текущие отображённые интервалы адресов у процесса, в Linux смотрим /proc/<pid>/maps, в OS X vmmap <pid>. У каждого интервала адресов есть три вида защиты: от исполнения, от записи и от чтения. Как видно, самый первый интервал, начинающийся с load address (соответствующий сегменту .text у ELF в Linux, __TEXT у Mach-O в OS X), доступен на чтение и исполнение — очень логично. Ещё можно увидеть, что стек по сути ничем не отличается от других интервалов, и можно быстро вычислить его размер, вычтя из конечного адреса начальный. Отображение страниц выполняется с помощью mmap/munmap, а защита меняется с помощью mprotect. Ещё существуют brk/sbrk, deprecated древние пережитки прошлого, которые изменяют размер одного-единственного интервала «данных» и в современных системах эмулируются mmap’ом.

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

• оптимально управляет уже выделенной памятью;
• значительно уменьшает количество обращений к ядру (ведь mmap / sbrk — это syscall);
• вообще абстрагирует программиста от виртуальной памяти, так что многие пользуются malloc’ом, вообще не подозревая о существовании страниц, таблиц трансляции и т. п.

Довольно теории! Будем щупать malloc на практике. Проведём три эксперимента. Работа будет возможна на POSIX-совместимых операционках, в частности была проверена работа на Linux и на OS X.