Знаете, когда я почти нечаянно обнаружил, читая прекрасную книгу Дмитрия Кетова «Внутреннее устройство Linux» (и это не реклама), что каждый скачанный нами файл из Интернета с легкой руки браузера оставляет в расширенных атрибутах файла (в inode файла, не в самом файле) как минимум полную ссылку на то откуда он был скачан, я пришел в легкое возбуждение и хотел тут же броситься спасать мир. Позже, немного изучив этот вопрос, почитав «коммиты» и «комменты», говорившие, что этой возможности, встроенной в ядро GNU/Linux, как минимум уже около 10 лет, что ею пользуется не только браузеры, но и, к примеру, популярная утилита wget (curl нет), и что эта вещь считается чуть ли не нормой в Linux (и, как выяснилось позже, в MacOS), то я немного подуспокоился. Одно не давало мне покоя: поиск ключевого слова getfattr в google по сайту «Хабра»: site:https://habr.com getfattr, равно как и по ЛОРУ: site:https://linux.org.ru getfattr ничего толком не дал. «Значит» — подумал я — «эта тема еще особенно не обсуждалась». — Что же, тогда пришло время ее обсудить, но для начала пришлось немного по-исследовать. И вот что я обнаружил:

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



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

Представляю на ваш суд ещё один перевод коанов о Мастере Фу на русский язык. В данный сборник вошли все коаны, на данный момент опубликованные на сайте Эрика Реймонда. Надо сказать, что сам Эрик личность весьма неординарная, но упоминания в данной статье стоящая. Помимо холиваров в списках рассылки всевозможных проектов за его авторством также несколько серьёзных трудов о Unix — в том числе и о сообществе, без которого экосистема современных открытых проектов не была бы возможной (полный список книг). Идея перевести коаны в очередной раз пришла мне в голову во время чтения одного из таких трудов, а именно «The Art of Unix Programming», поскольку многое из скрытого смысла коанов становится ясно только после прочтения очередной главы оттуда.

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

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

Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.

Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

Всем привет, я один из разработчиков сервиса SearchFace и готов поговорить о нём в комментариях.



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

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

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

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

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

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

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

Дисклеймер:

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

Не все пункты одинаково серьезны – в конце концов, у нас вечер пятницы, не так ли?

Итак:

«Уксусный коллектив четырёх воров» – сеть анархистов, опирающихся на технологии, и бросающих вызов гигантам фарминдустрии при помощи самостоятельно изготовленных лекарств

Впервые я познакомился с Майклом Лофером, когда он швырялся в аудиторию хакерской конференции HOPE (Hackers on Planet Earth), проходящей раз в два года в Нью-Йорке, лекарствами на тысячи долларов.

«Кто-нибудь из присутствующих переживал анафилактический шок, не имея доступа к эпинефрину?» – спросил Лофер у аудитории. Поднялось несколько рук, и Лофер швырнул одному из поднявших руку людей изготовленную в домашних условиях EpiPen [похожее на шариковую ручку устройство для самостоятельных инъекций адреналина / прим. перев.]. «Это одно из первых сделанных нами устройств, — сказал он. – Используйте его с умом».

Немного позлорадствовав насчёт того, как Мартин Шкрели из племени фармацевтических гигантов поднял цены на препарат дараприм, необходимый для людей, страдающих от ВИЧ, с $13 до $750, Лофер посерьёзнел. «Прошло два года, но несмотря на всё произошедшее, стоимость препарата дараприм не поменялась», — сказал он. Он залез в карман и достал пригоршню белых таблеток. «Думаю, надо раздать ещё немного», — сказал Лофер, и швырнул дараприм в аудиторию.

Осенью 2016 года нам с коллегой поручили улучшить документацию и контент в моей бывшей компании. Мы потратили год на все виды документации: справочник по API, руководства, учебные пособия, сообщения в блогах. До этого я 5 лет писала доки, но официально не обучалась этому. Но и неопытной меня нельзя назвать: кроме документирования API для проектов и стартапа, я ещё преподавала Python Flask на семинарах во время учёбы на последних курсах в университете. Но сейчас выпала возможность сосредоточиться только на любимом деле: помогать специалистам всех уровней через техническую документацию.

В этом году я многому научилась в сообществе Write The Docs, у других провайдеров API, а также методом проб и ошибок. В прошлом году я поделилась опытом в докладе «Что мне хотелось бы знать о написании документации» на конференции API Strategy and Practice в Портленде. Эта статья — обзор полученных знаний.

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

Источник

Всем привет. Это моя юбилейная статья на Хабре. За почти 7 лет я написал 10 статей (включая эту), 8 из них — технические. Общее количество просмотров всех статей — около полумиллиона.
Основной вклад я внёс в два хаба: PHP и Серверное администрирование. Мне нравится работать на стыке этих двух областей, но сфера моих интересов гораздо шире.

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

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

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

Месяц назад портал на моей новой работе был взломан. Руководство задалось вопросом «Как?». В ходе недолгих поисков и анализу подключений к серверам, был найден ПК сотрудника, с которого устанавливалось подключение примерно в то самое время. Сотрудник ничего о взломе не знал, но в ходе беседы вспомнил один случай, ему незадолго до взлома пришёл документ от «сотрудника фирмы», который не открылся. Файл был в формате exe, с этого и началась вся история.

Привет! Я руковожу небольшим ИТ-аутсорсингом, и к нам в прошлом году обратилось сразу несколько клиентов с похожими задачами — сделать так, чтобы никто не узнал, где именно стоят сервера компании.

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

Мы придумали вот такую схему:



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

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



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

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

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

Зачем это нужно?

В идеале, семантическая система «понимает» содержание обрабатываемых статей в виде системы смысловых понятий и выделяет из них главные («о чем» текст). Это дает огромные возможности по более точной кластеризации, автоматическому реферированию и семантическому поиску, когда система ищет не по словам запроса, а по смыслу, который стоит за этими словами.

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

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Наш первый пост в этом году мы решили посвятить очень базовой теме, лекция на которую была прочитана в Малом ШАДе. Занимаются в нём старшеклассники, которым интересны технологии, отсюда специфичность изложения — лекция будет особенно интересна тем, кто только начинает программировать и задумывается о том, в каком направлении развиваться. Для них же у Яндекса есть курс «Введение в программирование (С++)», который можно пройти на платформе Stepic.org.

Лектор Михаил Густокашин — куратор академических программ Яндекса, директор центра студенческих олимпиад факультета компьютерных наук ВШЭ. Михаил подготовил десятки победителей и призёров Всероссийских олимпиад по программированию.



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

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