Конференции бывают разные. Некоторые собирают огромные толпы зрителей, другие могут быть интересны лишь полутора специалистам.

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

На самом деле, пост не о том.

Так уж вышло, что мне довелось выступать на означенной конференции, где я на пальцах и с приплясываниями рассказывал, что такое LLVM, чем интересна нотация SSA, что такое IR код и, наконец, как так получается, что детерменированные на первый взгляд C++ программы, оказывается, провоцируют неопределенное поведение.

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

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

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

Что же делать? Показать решение типового задания с ранних курсов или дипломный проект? Возможно, этого мало? Может быть, написать какую-нибудь впечатляющую программу и заодно получить опыт разработки? Например… калькулятор или компилятор или что там обычно пишут для получения и показа опыта? А если не хватит сил закончить?

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

Зачем и для кого статья?

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

Здесь не будет пересказа манов (документации), и статья никак не отменяет и не заменяет их чтение. Вместо этого я расскажу о главных вещах (командах, приемах и принципах), которые надо осознать с самого начала работы в unix shell-е, чтобы работа происходила эффективно и приятно.

Статья касается полноценных unix-подобных окружений, с полнофункциональным шеллом (предпочтительно zsh или bash)и достаточно широким набором стандартных программ.

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

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

Теперь давайте реализуем непосредственно операции обновления БД: создание, обновление, удаление наших записей и соответствующий им интерфейс командной строки.

Введение

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

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

Всем привет.

Какое-то время назад я видел в небезызвестном блоге пост о том, как реализовать на Go простую программу, работающую с БД, а затем сделать на её базе целый REST-сервис. Я решил проверить, насколько сложно сделать аналогичную программу на Rust и поделиться результатами.



Мы начнём с работы с БД и создадим обычное консольное приложение, а затем добавим, так сказать, REST-фронтенд.

Микрософт с помощью пасьянса и косынки учила пользователей пользоваться мышью,
теперь с помощью windows 10 учит читать лицензионное соглашение.

После выхода windows 10 сразу появились сообщения о сборе информации о действиях пользователей и много обсуждений, что делать. Достаточно быстро пользователи составили список основных серверов, собирающих информацию и попытались их заблокировать через файл hosts. Но скептики сразу выдвинули здравое предположение, что MS мог предусмотреть этот метод и некоторые адреса прописать в коде. Тем более, что MS всегда может актуализировать адреса серверов через windows update.

В нашей компании начали появляться первые пользователи windows 10, и мы решили опробовать блокировку передачи телеметрии через встроенный windows firewall.

Опен сорс заставляет меня чувствовать себя мазохистом.
Я люблю его, однако часто работа с ним – боль.
(c) Мой

Когда-то – может, уже лет 10 назад – было модно предрекать конец опен сорсу. Интернет пестрил заголовками типа «Почему Open Source скоро умрет» или «Почему Open Source никогда не победит платное ПО». Это не точные заголовки. Скорее, впечатление, которое сохранилось с тех пор.

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

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

Я запланировал три поста, которые опубликую, если тема покажется интересной:

1. Этот пост, где поговорим о том, как научиться понимать Open Source
2. Модели использования Open Source для достижения бизнес-целей
3. В третьем посте я предложу нестрогую классификацию открытого кода по его профпригодности. По тому, насколько удобно, эффективно и полезно работать с различными сторонними проектами.

Привет, Хабрахабр! Недавно мы анонсировали конкурс для разработчиков приложений, и в посте на Хабре давали ссылки на самые интересные материалы по Material Design’у. Часть из них имела пометку «RU — скоро», и сегодня мы рады представить вам первую адаптированную статью о том, как создатели приложения Feedly адаптировали его к новому визуальному языку Android-приложений.

Кажется, нас давно тут не было, и мы возвращаемся и возвращаемся не с пустыми руками: та-дам! До определенного момента Lingualeo был отличным способом пополнять словарный запас свежими идиомами и «живой» лексикой спикеров TED. Вы могли развивать навыки, изучая интересный контент. Но сегодня все изменилось.

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

Тихо и незаметно (с), вышел Python версии 3.5! И, безусловно, одно из самых интересных нововведений релиза является новый синтаксис определения сопрограмм с помощью ключевых слов async/await, далее в статье об этом.

Поверхностный просмотр «PEP 0492 — Coroutines with async and await syntax» поначалу оставил у меня вопрос «Зачем это надо». Сопрограммы удовлетворительно реализуются на расширенных генераторах и на первый взгляд может показаться, что все свелось к замене yield from на await, а декоратора, создающего сопрограмму на async. Сюда можно добавить и возникающее ощущение, что все это сделано исключительно для использования с модулем asyncio.

Но это, конечно же, не так, тема глубже и интереснее.

Здравствуйте, уважаемые читатели!

Жизнь не стоит на месте, и вот в «O'Reilly» задумались об издании первой фундаментальной книги о языке программирования Rust:



Заинтересовавшись этой темой, мы решили вынести на обсуждение перевод обзорной статьи о языке Rust, вышедшей в декабре 2014 года. Статья немного сокращена с учетом того, что некоторые ее отрывки уже устарели, однако автор хорошо рассматривает этот язык в контексте существующих альтернатив, подчеркивает его (безусловные) достоинства и (условные) недостатки.

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

Сегодня завершаются циклы стабильного Rust 1.2 и бета-Rust 1.3! Читайте дальше об основных изменениях или переходите к более подробным release notes.

Представлена альфа версия патча, обеспечивающего поддержку HTTP/2 для NGINX. Для данного патча необходим NGINX версии 1.9.0 или новее. Полная поддержка протокола HTTP/2 для коммерческой и некоммерческой версий NGINX планируется к концу этого года. Отзывы можно отправить в рассылку nginx-devel.

Так как патч является альфа версией, не рекомендуется его использовать в рабочих проектах. Если есть желание использовать особенности HTTP/2 для рабочих сайтов, следует обратить внимание на NGINX версии 1.5.10 и более новых, в которых реализована полная поддержка протокола SPDY/3.1. Как предшественник HTTP/2, SPDY обладает такими же приемуществами как и HTTP/2, но в то же время имеет более широкую поддержку среди актуальных версий браузеров.