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

design

Когда появляется программа? Скорее всего, программа появляется в голове у проектировщика/разработчика, можно назвать это design-time. Но так как этот момент не поддаётся контролю компьютера (пока), то предположим, что моментом появления программы является момент создания минимального запускаемого (о подробном смысле этого термина стоит поговорить отдельно) исходного кода.

Сегодня речь пойдёт о новом алгоритме блочного шифрования «Кузнечик» из стандарта ГОСТ Р 34.12 2015. В последнее время выходит множество публикаций, посвященных этому стандарту. В них с теоретической точки зрения описываются приведённый алгоритм, изучаются особенности отельных преобразований, а так же предлагаются способы оптимизации, путём включения вставок кода на языке ассемблера.

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

Структура программы

Программа состоит из трех частей

• набор вспомогательных функций и классов — mycrypto.cpp mycrypto.hpp
• блочный шифр «Кузнечик» — Kuznyechik.cpp Kuznyechik.hpp
• режим шифрования Cipher Feed Back — modes.hpp

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



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

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

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

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

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

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

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

Идею проекта SKY можно излагать по разному, но самое короткое и простое изложение следующее. В интернете существует много сайтов, сила которых в основном обусловлена текстовым и фото-видео контентом пользователей, но нет ни одного, сила которого бы была обусловлена кодом пользователей. Уточню: конечно, есть сайты сохраняющие код пользователей, например «packagist.org», но нет ни одного, которые бы могли достигнуть уровня популярности социальной сети в отношении кодового контента (назовем это цель X), в котором ведется активный скрупулезный анализ всех деталей кода многими участниками. Так сайт packagist сопоставим с проектом SKY, достигшем цели X, также, как можно сопоставить любую инсталляцию форума phpbb с сайтом Facebook. В данный момент проект SKY мало известен, но возможна ли указанная популярность? Моё мнение – конечно, и ключ к этому — простота, следование принципам KISS в дизайне кода. Имхо, и php достиг высокой популярности, в первую очередь, благодаря простоте.

Ноябрь считается месяцем литературного творчества. Каждый год в интернете проходит мероприятие NaNoWriMo (National Novel Writing Month). Участники должны до конца месяца написать новеллу длиной не менее 50000 слов. За 17 лет в нем поучаствовали больше 20000 человек.

В 2013 году у программистов появилось аналогичное соревнование — NaNoGenMo (National Novel Generation Month). Задача NaNoGenMo — написать программу, которая сгенерирует новеллу длиной 50000 слов или больше. При этом требования к новелле довольно слабые — подойдет любой текст достаточной длины. Как вы увидите, это может быть сборник рассказов, пьеса, кулинарная книга, словарь или туристический путеводитель. На самом деле, произведение не обязано даже быть текстовым.

Графическая новелла «Сгенерированный детектив»

«Вкус — это способность судить о прекрасном»
И. Кант

Дирк Хондел, один из тех, кто стоял у истоков Linux, однажды сказал о создателе Linux Линусе Торвальдсе: «Линус не только блестящий программист: у него хороший вкус. Торвальдс находит простые и разумные пути решения проблем, умеет всё «разложить по полочкам». Сложные вещи он делает простыми. По-моему, это и есть главное отличие превосходного программиста от просто хорошего».


В недавнем интервью, примерно на 14-й минуте, Линус Торвальдс коснулся темы «хорошего вкуса в программировании». Хороший вкус? Ведущий попросил его остановиться на этом подробнее, и Линус, пришедший не с пустыми руками, показал пару слайдов.

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

Развлекаемся, «распутывая» код на языке Си

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


Когда я в очередной раз просматривал книгу «Expert C programming», я вдруг наткнулся на раздел «light relief» в международном конкурсе на самый запутанный код на Си (IOCCC). Это соревнование по написанию как можно более нечитабельного кода. То, что такие конкурсы устраиваются для Си, наверное, говорит что-что об этом языке. Мне хотелось увидеть работы участников этого соревнования. Не найдя никакой информации в интернете, я решил поискать их самостоятельно.

IOCCC был придуман Стивеном Борном, когда он решил использовать препроцессор Си и написать Unix shell как бы на языке Си, но больше похожем на язык Algol-68, с его явными окончаниями операторов, например:

if
  ...
fi 

Он добился этого, сделав:

#define IF if(
#define THEN ){
#define ELSE } else {
#define FI ;}

Что позволило ему писать так:

IF *s2++ == 0
THEN return(0);
FI

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



Если есть сомнения в том, что это действительно необходимый навык, вспомните этот ужасный, но часто задаваемый вопрос: «Как много времени это займёт?». Даже если вы супер-Agile и не верите в дедлайны, будьте уверены, что кто-нибудь сломается под давлением и выдаст дату, к которой и будет привязана ваша команда. И когда эта дата наступит, а вы не будете готовы к запуску, ваш менеджер будет злиться, потому что из-за вас она будет глупо выглядеть; отдел продаж будет злиться, потому что они обещали самым важным заказчикам продукт уже сегодня; и ваша команда тоже будет злой, потому что они работали пять выходных подряд пытаясь вложиться в невозможный дедлайн. Так что давайте избежим всего этого и создадим план, пригодный к жизни.

Для примера я хочу предложить упражнение, которое я позаимствовал из курса “Intro to Development” от Microsoft. Цель – оценить время покраски комнаты. Это тот тип упражнения, который не требует каких-то специфичных знаний о какой-то системе.

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

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

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

Для слабых разработчиков работа в изоляции может стать непреодолимым препятствием

Опустим вопрос, зачем это нужно. Это одна из немногих компактных операционных систем open source с поддержкой русского языка, которые шагнули дальше концептуальной версии.

Что нужно для начала разработки для Колибри ОС (КОС)?

Источниками информации для вас будут (начало тут):

• Форум, чтобы знать в каком направлении двигаться;
• Вики, хотя к сожалению достаточно фрагментирована, но даст необходимый минимум обзорной информации;
• Исходные тексты программ в хранилище Subversion (SVN);
• Справочник по системным функциям на русском и английском языке SVN:/kernel/trunk/docs/sysfunc*.txt, или на Вики;

Я выступал на DomCode в ноябре 2015 года (отличная конференция, кстати; проходила в маленьком красивом городке) и рассказывал о своем списке правил для построения open source сообществ. Один человек позже попросил меня объяснить, почему я советую мерджить патчи быстро, не дожидаясь завершения тестирования непрерывной интеграции (Continuous Integration) и без перепроверки кода. Я буду называть эту стратегию optimistic merging (ОМ). И сейчас я расскажу о некоторых ее плюсах.

Стандартная практика для многих сообществ — пессимистичный мерджинг (ПМ). Это когда нужно сначала дождаться, пока тестирование непрерывной интеграции завершится, потом пересмотреть код, потом протестить патчи на ветви и затем дать фидбэк автору. Тогда только он может пофиксить патчи, и весь этот цикл начнется заново. На этой стадии сопровождающий запросто может сказать: «Мне не нравится, как вы это сделали» или «Это не совпадает с нашем видением проекта».

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

Насколько сложно построить полноценный сервис email-маркетинга? Что для этого нужно предусмотреть? Какие подводные камни могут встретиться на пути пытливых умов разработчиков?



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

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

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

Предыстория и проблематика

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

Получилось похоже на MS Visio с определенной степенью кастомизации и плагинизации. Никаких технических сложностей здесь нету, однако есть ряд особенностей.

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

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

В-третьих, когда я сделал все, что хотел, и показал результаты другу (который даже не программист), то он потыкал и сказал, что неплохо бы сделать Ctrl+Z. Я загорелся идеей, но вот реализовать это оказалось не такой тривиальной задачей. В этой статье я опишу, к чему пришел в итоге.

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

Тогда я написал пост «Заблуждения программистов относительно „времени“», в котором указал 34 ошибочных представления и заблуждения, относящихся как к календарному, так и к системному времени. С большинством из них я столкнулся сам, занимаясь дебаггингом программ (как рабочих, так и тестовых).

Теперь онлайн-курсы «Разработка на Java 1», «Разработка на Java 2» и «Анализ безопасности веб-проектов» на платформе Stepik.org лежат в свободном доступе! Мы убрали дедлайны, чтобы вы прошли курсы в удобное время и получили сертификаты. В ближайшие десять дней мы перезапустим еще два онлайн-курса. «Постановка задач на разработку ПО» откроется 28 октября, а 3 ноября станут доступны «Web-технологии».

Stepik.org — платформа онлайн-курсов. С ее помощью можно научиться чему-либо прямо из дома — нужен только доступ в интернет. Авторы рассказывают материал на видеолекциях и предлагают выполнить практические задания. Большинство курсов открыты только в отведенное время — это стимулирует нерешительных участников записываться. Курс делится на модули, которые нужно сдавать в срок. Наличие дедлайнов повышает мотивацию студентов. Справляются не все — сертификаты получает в среднем 9% учащихся. Открытый доступ решает проблему времени, теперь нужно только желание.

Первый курс от Mail.Ru Group открылся 1 сентября 2015 года. С этого момента к нам записались 50 000 человек, которым мы выдали 4 500 сертификатов. В феврале этого года на «Web-технологии» зарегистрировалось 8 500 человек. Это в два раза больше среднего, поэтому мы хотим рассказать об этом курсе.

От переводчика:
Уже опубликовано много материалов по MVC и его производным паттернам, но каждый понимает их по-своему. На этой почве возникают разногласия и холивары. Даже опытные разработчики спорят о том, в чем отличие между MVP, MVVM и Presentation Model и что должен делать тот или иной компонент в каждом паттерне. Ситуация усугубляется еще и тем, что многие не знают истинную роль контроллера в классическом варианте MVC. Предлагаю вашему вниманию перевод хорошей обзорной статьи, которая многое проясняет и расставляет всё по своим местам.

JavaScript сильно изменился за последние годы. Вот 12 новых возможностей, которые можно начать использовать уже сегодня!

История

Новые добавления в язык называются ECMAScript 6. Или ES6 или ES2015+.

С момента появления в 1995, JavaScript развивался медленно. Новые возможности добавлялись каждые несколько лет. ECMAScript появился в 1997, его целью было направить развитие JavaScript в нужное русло. Выходили новые версии – ES3, ES5, ES6 и так далее.

Как видите, между версиями ES3, ES5 и ES6 есть пропуски длиной в 10 и 6 лет. Новая модель – делать маленькие изменения каждый год. Вместо того, чтобы накопить огромное количество изменений и выпустить их все за раз, как это было с ES6.

Разговор вёл IvanPonomarev

Test-driven development (TDD) — практика, известная уже довольно давно. Разработка через короткие циклы «прежде всего пишем юнит-тест, затем код, потом проводим рефакторинг, повторяем» в ряде компаний принята в качестве стандарта. Но обязательно ли команда, достигшая хорошей степени зрелости процесса разработки, должна принимать TDD? Как и для большинства других практик Extreme Programming, споры по поводу TDD до сих пор не стихают. Оправдываются ли первоначальные затраты на обучение и внедрение TDD? Даёт ли TDD ощутимый выигрыш? Можно ли этот выигрыш измерить? Нет ли случаев, когда TDD проекту вредит? А есть ли ситуации, когда без TDD решить задачу просто невозможно?

Об этом мы поговорили с разработчиками-экспертами Андреем Солнцевым asolntsev (разработчик из таллинской компании Codeborne, который практикует Extreme Programming и придерживается TDD) и Тагиром Валеевым lany (разработчик в JetBrains, также разрабатывает опенсорсную библиотеку StreamEx и анализатор байткода Java HuntBugs; убежден, что TDD — бесполезная практика). Интересно? Добро пожаловать под кат!

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