Работая в компании, которая занимается системной интеграцией, мне приходилось много раз читать и дополнять документы типа ТКП, ТЗ по ГОСТу, Планы приемки и прочее. Проекты по автоматизации предприятий преследовали похожие цели и имели приблизительно одинаковый формат. Одни и те же фразы повторялись из документа в документ.

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

Список не универсальный. Буду рада, если кому-то это поможет при написании документов.

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

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

Долго мучился с PyCrypto, в итоге получилась эта статья и полная реализация следующего протокола:

Этап отправки:

1. Алиса подписывает сообщение своей цифровой подписью и шифрует ее открытым ключом Боба (асимметричным алгоритмом).
2. Алиса генерирует случайный сеансовый ключ и шифрует этим ключом сообщение (с помощью симметричного алгоритма).
3. Сеансовый ключ шифруется открытым ключом Боба (асимметричным алгоритмом).
Алиса посылает Бобу зашифрованное сообщение, подпись и зашифрованный сеансовый ключ.

Этап приёма:

Боб получает зашифрованное сообщение Алисы, подпись и зашифрованный сеансовый ключ.
4. Боб расшифровывает сеансовый ключ своим закрытым ключом.
5. При помощи полученного, таким образом, сеансового ключа Боб расшифровывает зашифрованное сообщение Алисы.
6. Боб расшифровывает и проверяет подпись Алисы.

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

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

Аттеншн, лонгрид!

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

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

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

Доброго времени суток, Хабрахабр! Данный материал является продолжением первой части, в которой освещены инструменты и возможности разработки продукта на облачной платформе. Примером является актуальное мобильное расширение доступа к расписанию пар в университете — Telegram-bot.

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

В 1971 году СССР доставили на Марс первые в мире планетоходы «на лыжах», которые должны были щупом (динамический пенетрометр и гамма-лучевой плотномер) ткнуть поверхность, и сказать — Марс твердый или жидкий пыльный. Первый аппарат разбился 27 ноября, второй совершил мягкую посадку 2 декабря, но марсоходик не смог выбраться из «скорлупы» посадочного модуля, поэтому попытку не засчитали.

Прошло 25 лет.
4 июля 1997 года на Марс прилетел американский аппарат и привез «пришельца» с первым багом.


Кадр из к/ф «Марсианин». Главный герой держит в руках марсоход Sojourner

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

В этой небольшой статье я хотел бы рассказать о средствах мониторинга, использующихся для анализа работы DWH нашего банка. Статья будет интересна всем, кого не устраивают существующие готовые системы мониторинга и кого посещали мысли собрать таковую «под себя» из отдельных кусочков. Большое внимание в статье уделяется дашборду Grafana, который, по моему мнению, незаслуженно обделён вниманием на Хабре. По большинству компонентов системы мониторинга будет вкратце рассмотрен процесс инсталяции (под RedHat).


Тёплый ламповый дашборд

Сегодня я расскажу, что из себя представляет Instana, и чем эта система мониторинга (СМ) отличается от других.

Привет, Хабр! Спешим сообщить тебе, что трансляции с Хайлоада уже выложены на Youtube-канале Хабра. Напоминаем — что это плод специального проекта Хабра и Хайлоад. 7 ноября, текстовая трансляция, несколько сотен постов (доступна здесь). 8 ноября, текстовая трансляция – тут. Наверняка не у всех была возможность наблюдать за этим онлайн, поэтому спешим сообщить, что теперь доступна запись конференции, которую вы можете посмотреть в любое удобное для вас время на YouTube канале Хабра. Страницу специального проекта просмотрели больше 25 000 раз, текстовую трансляцию прочитали больше 9 000 человек, а видео на ютубе посмотрели на данный момент 10 000 человек.  Ну что ж, надеемся, что это помогло читателям Хабра немного погрузиться в новое или горячо любимое, расширить свой кругозор и найти для себя что-то полезное в самой гуще высококонцентрированных докладов о высоких нагрузках.

Этот пост является 3-й частью статьи «Создание игры «The Contender» («Соперник»)»: концепция завершения". Здесь ссылки на часть 1 (как мы сделали игру) и часть 2 (как мы запускали проект на Kickstarter).

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

Я — Джон Тисдэйл. Мы с другом создали «The Contender» («Соперник»): игра на тему президентских дебатов. 9 сентября 2015 года мы собрали 127 827,01 долларов США на Kickstarter. Казалось бы — очень большие деньги, но лишь на этой неделе, 22-го ноября 2016 года, мы, наконец, расплатились с долгами. Прошло 440 дней работы после создания продукта и кампании на Kickstarter, прежде чем мы получили 1 доллар.

Мы не ожидали, что так будет.

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

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


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

Написано, т.к. возник очередной холивар в комментариях на тему SQL vs ORM в High-Load Project (HL)

Преамбула

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

• Никогда нельзя реализовать HL-проект на основе только одной манипуляции с ORM
• Никогда не складывайте сложные вещи на плечи БД. Она нужна Вам чтобы хранить инфу, а не считать факториалы!
• Если вы не можете реализовать интересующую Вас идею простыми средствами ORM — не используйте ORM для прямого решения задачи. И тем более не лезте в более низкий уровень, костыли сломаете. Найдите более элегантное решение.
• Извините за издевательски-юмористический тон статьи. По другому скучно :)
• Вся информация взята по мотивам Django версии 1.3.4
• Будьте проще!

И-и-и да, в статье будут показаны ошибки понимания ORM, с которыми я столкнулся за три с лишним года работы с Django.

Доброго времени суток, Хабрахабр! Целью статьи является рассказать начинающим программистам о возможности не только разработать что-то интересное на основе несложных инструментов, но и разместить проект в общий доступ, а при усердных стараниях увидеть, что не только автор может оценить потраченные усилия.

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

Т.к. мой классификатор из прошлого поста таки работает (впрочем, параметры «из коробки» не всегда удачны, потому я вынес возможность слегка настроить Conv1d-слои и скрытый слой) — я решил прикрутить его к боту. Да, запоздал я на этот хайп ) Кстати, заранее уточню, что прикрутить русский я пока таки не пробовал, хотя это не должно стать проблемой — в nltk поддерживаются нужные фичи, обучение word2vec концептуально не отличается от английского, да и предобученные модели вроде бы имеются.

Ну и сходу возникают вопросы:

• под какие платформы его пилить — пока решил остановиться на telegram. В теории — конструкция позволяет легко дописать обертки для других платформ (как будто он кому-то понадобится )
• как описывать «сценарий». Навелосипедил свою структуру с классами и сущностями поверх YAML
• ну и неплохо бы хранить ботов/состояние в какой-нибудь БД

На протяжении долгого времени я не до конца понимал htop. Я думал, что средняя загрузка [load average] в 1.0 означает, что процессор загружен на 50%, но это не совсем так. Да и потом, почему именно 1.0?

Затем я решил во всём разобраться и написать об этом. Говорят, что лучший способ научиться новому — попытаться это объяснить.

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

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

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

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

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.

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

На днях произошло, в какой-то степени, знаменательное событие и одна из крупнейших компаний России заявила о том что теперь публикует открытые данные на своем сайте. Этой компанией является Сбербанк и соответствующий раздел на их сайте. Открытие раздела удостоилось пресс-релиза на их сайте и о нем, как о важном событии, написали десятки финансовых и не финансовых СМИ.

Действительно ли Сбербанк совершил нечто невероятное? Рядовое ли это явление и является ли то что сделал Сбербанк сейчас открытыми данными? Вот о чем далее пойдет речь.

В качестве вступления

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

Как бы мы не относились к качеству адресов ФИАС с ними необходимо работать, потому что это единственный общероссийский справочник адресов. Поэтому рано или поздно приходится решать задачу связи местоположения объектов недвижимости, юридических и физические адресов с адресом из ФИАС.

В этой статье изложен опыт работы со списком адресообразующих элементов ФИАС, загруженным в базу данных под управлением PostgreSQL. Для работы с адресообразующими элементами ФИАС создано несколько функций на языке PL/pgSQL.