В мире наступили восьмидесятые. IBM захватывал рынок профессиональных компьютеров своими PC и PC XT — родоначальниками всех современных настольных компьютеров. Джобс одну за другой выпускал новые модели Apple. Commodore 64 и ZX Spectrum гремели по миру. А в это время в советском блоке продолжали выпускаться Ascota 170 — механические компьютеры родом из начала пятидесятых. Почему-то, в рунете (да и в остальном интернете тоже) мало говорят об этих удивительных машинах, едва ли не единственных серийно (больше трёхсот тысяч с 1955 до 1983 годов) выпускавшихся Тьюринг-полных механических компьютерах. Я и сам о них узнал только тогда, когда Аскота случайно попала мне в руки.
Надеюсь, моя статья сможет изменить это.


Моя Аскота закончила считать квадратный корень из 2.

^{Принципиальная схема змеи, рисовала прекрасная Ш.А.Г. с моих слов}

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

Ну и вокруг них много недопонимания.

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

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

Но начнём с разбора змеи. С корпуса.

Здравствуйте, в эфире снова Радио SQL! Разминайте ганглии, расправляйте псевдоподии (или наоборот?) и настраивайтесь на нашу гравитационную волну!

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

А если на вашей работе начнут давать айфон каждый месяц за… Ну, за что-нибудь? Не за основную работу, а за, скажем так, активное участие в жизни компании. Попробуете?
Мы попробовали. Получилось прикольно.

Всем привет! 16 июня, в нашем московском офисе пройдет очередной DIY-митап! Прошлый ивент состоялся аж в далеком феврале, настало самое время достать из гаража свои изобретения, стряхнуть с них пыль и рассказать всем!

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

«Нам нужен DevOps!»
(самая популярная фраза в конце любого хакатона)

Сначала немного лирики.

Когда разработчик является отличным девопсом, умеющим развернуть своё детище на любой машине под любой OC, это плюс. Однако, если он вообще ничего не смыслит дальше своей IDE, это не минус — в конце концов, деньги ему платят за код, а не за умение его разворачивать. Узкий глубокий специалист на рынке ценится выше, чем средней квалификации «мастер на все руки». Для таких, как мы, «пользователей IDE», хорошие люди придумали Docker.

Принцип Docker следующий: «работает у меня — работает везде». Единственная программа, необходимая для деплоя копии Вашего приложения где угодно — это Docker. Если Вы запустили своё приложение в докере у себя на машине, оно гарантированно с тем же успехом запустится в любом другом докере. И ничего, кроме докера, устанавливать не нужно. У меня, к примеру, на виртуальном сервере даже Java не стоит.

В комментариях к моей статье Docker: вредные советы было много просьб объяснить, чем так ужасен описанный в ней Dockerfile.

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

Сейчас разберемся, что не так с этим Dockerfile.

Итак, прошла неделя.

Привет! Меня зовут Олег, и я frontend-разработчик в Альфа-Банке. Я хочу рассказать вам немного философскую историю — про инженерный подход к разработке, про мою первую работу и грабли, которые я там собрал, про то, почему чеклисты очень важны (и спасают жизни).

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

Всё началось с хаоса.

О нас

Доброго времени суток, Хабр! Мы компания «Информационный центр». Наше основное направление – информационная безопасность (она же – ИБ). В ИБ мы занимаемся практически всем: аудитом, проектированием систем защиты, аттестацией, комплаенсом, пентестами, есть свой SOC, даже с гостайной работаем. Поскольку мы базируемся во Владивостоке, изначально мы работали больше в Приморском крае и в дальневосточных регионах страны, но в последнее время география наших проектов все дальше раздвигает немыслимые нами в момент основания границы.

В первой своей статье мы хотели бы рассмотреть такую сторону ИБ, как комплаенс (англ. complience – соблюдение, соответствие). И поговорим мы о том, что нужно сделать, чтобы полностью соответствовать российскому законодательству о персональных данных.

Случалось ли вам видеть автоматизацию производственного предприятия, выполненную за 2 месяца? Или, может быть, доводилось делать такую автоматизацию? Я уверен, таких примеров много. У меня тоже есть – кидаю в копилку.

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

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

Изменения в сложных программных системах, кажется, занимают вечность, не так ли? Даже инженерам часто кажется, что изменения идут больше положенного, хотя мы сознаём всю сложность системы!

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

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

Ну ладно, про «полюбил» — это преувеличение. Скорее «смог сосуществовать с».

Как вы все знаете, с 16 апреля 2018 года Роскомнадзор крайне широкими мазками блокирует доступ к ресурсам в сети, добавляя в "Единый реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено" (по тексту — просто реестр) по /10 иногда. В результате граждане Российской Федерации и бизнес страдают, потеряв доступ к необходимым им совершенно легальным ресурсам.

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

Привет! Я три года назад читал в детском лагере лекцию про социнжиниринг, троллил детей и немного бесил вожатых. В итоге испытуемые спросили, что почитать. Мой дежурный ответ про две книги Митника и две книги Чалдини, вроде, убедителен, но только для примерно восьмиклассника и старше. Если младше — то надо сильно чесать голову.

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

У нас не очень простое собеседование. Нужно пройти 3 шага:

1. Прислать резюме, программист его посмотрит, лайкнет если всё хорошо. Рекрутер позвонит, задаст несколько вопросов.
2. Встретиться или созвониться с нами. Узнаем, какой вы специалист.
3. Прийти на тестовый день. Познакомиться с командой и поработать вместе. Пообщаться с техническим директором, обсудить зарплату и получить оффер.

Я три месяца был тем программистом, который оценивает резюме. Мне есть о чём с вами поговорить.

На волне внедрения DevOps да и в целом развития ИТ в массах всё больше и больше становится популярным использование СПО (Свободное Программное Обеспечение). Даже Microsoft очень неплохо приложило руку к тому, чтобы популяризировать СПО в массах. Одна проблема — пользователи это потребители, а кто-то (наверняка кто-то да был) внушил этим пользователям, что в СПО действуют те же правила, что и в коммерческом софте, только при этом ничего не нужно платить.

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

Что? Строки могут быть «грязными»?

Да, могут.

//.....Какой-то код
console.log(typeof str); // string
console.log(str.length); // 15
console.log(str); // "ччччччччччччччч"

Вы думаете, в этом примере строка занимает 30 байт?

А вот и нет! Она занимает 30 мегабайт!

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

Осторожно! Много картинок и трафика!

Сравнение двух подходов структурирования диаграммы Activity (по мотивам "Белки")

В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди" А.С.Пушкина. И начали мы с диаграммы Activity, договорившись о структурировании поля диаграммы с помощью «плавательных» дорожек – Swim lanes. Имя дорожки соответствует типу элементов диаграммы, которые присутствуют на этой дорожке: «Входные и выходные артефакты», «Шаги процесса», «Участники» и «Бизнес-правила». Этот подход отличается от стандартного, когда дорожки обозначаются именами участников процесса, таким образом закрепляя за ними определенные зоны ответственности в процессе.

В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].

Подробнее о применяемых подходах к моделированию см. [2].

Полную спецификацию UML см. здесь [3].

Однажды мне в журнале «ЮТ для умелых рук» №1, 1989 г. попалась статья с названием «Загадочная ампула», рассказывающая о необычном старинном метеорологическом приборе – штормглассе (stormglass, camphor glass, weatcher glass, склянка Фицроя, штормовая склянка), изготовил прибор по предложенной рецептуре, стал изучать дальше, некоторыми сведениями и своим опытом, в основном практического плана, далее и поделюсь.

Есть информация, что штормгласс использовался уже в XVIII веке, но самое известное упоминание связано с Робертом Фицроем, капитаном судна Бигль, на котором путешествовал Чарльз Дарвин, ему же (Р. Фицрою) часто ошибочно приписывают изобретение прибора. Классический штормгласс представляет собой герметичный вытянутый стеклянный сосуд, заполненный почти доверху прозрачной жидкостью с бесцветными кристаллами разнообразной формы. По изменению внешнего вида, положению и высоте этих кристаллов полагается судить о погоде на следующие часы и дни. В своё время его применяли совместно с барометром, а в настоящее время штормгласс рассматривается больше, как необычное украшение для интерьеров, многие современные исследователи пришли к мнению, что основную свою функцию прибор не выполняет, но исследования и споры вокруг него всё ещё ведутся. Даже если штормгласс и не реагирует ни на что кроме температуры, всё равно это интересная и красивая вещь, которая вполне может выполнять роль украшения. Можно, конечно, купить готовый, в сети довольно много предложений (особенно на eBay и AliExpress), но в таком случае отсутствует информация о том, как и из чего прибор был изготовлен, а также удовольствие от вещи, сделанной своими руками.

Кто эти люди и что их объединяет, помимо длины волос? Многие геймеры наверняка узнали по фотографии Джона Ромеро, сторонникам свободного ПО не нужно представлять Ричарда Столлмана, а пользователи PostgreSQL могут хорошо знать Олега Бартунова. Кое-что общее уже заметно: все трое много лет в IT и причастны к популярным проектам. Но как три человека, занимающиеся настолько разными вещами, оказались на одном изображении?

Причина в том, что они окажутся на одном мероприятии — и вы тоже можете там оказаться. 24-25 августа мы проведём в Петербурге IT-фестиваль TechTrain, где в числе спикеров будут эти три человека. А что ещё там будет?