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

Дело было в том, что у нас в Питере не найти в книжных магазинах рабочую тетрадь по английскому языку "Планета знаний" 3 класс. Ну как в Союзе было, дефицит. И мне жена дала задание — зайти в книжные в Москве. Дескать, в столице все есть, тетки на форуме оттуда заказывают, платят 500 рублей за доставку, а ты, пользуясь случаем, купишь сам и сэкономишь для семьи. Хоть какой-то толк от неудачника будет. Я включаю Гугль-карту, задаю фразу "книжные магазины" и не понимаю. Ни Красной площади, ни реки, какие-то непонятные улицы.

Черт! Он вылез опять! Я ведь еще успел только до Варварки дойти.

И, повинуясь зову природы, я расчехлил опять свое оружье.

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

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

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

Введение

Химкомбинат «Маяк» (Комбинат №817), расположенный в городе Озёрск (Челябинская область, Российская Федерация), или же Челябинск-40 (1948-1966), или же Челябинск-65 (1966-1994), или же «Сороковка» (как город именовали его жители), широкую известность получил в СССР только в 1989 году. До этого про него знали лишь немногие. Тем более про то, что произошло на данном комбинате 29 сентября 1957 года: одна из самых больших ядерных катастроф в истории человечества. И если про события на четвертом энергоблоке на АЭС в Чернобыле 26 апреля 1986 года знает каждый школьник и житель страны, то про сентябрьские события 1957 года на секретном химкомбинате в Уральских горах известно лишь некоторым.
Скажу честно, что промышленность – это совсем не моя тема. Но так самая страшная ядерная катастрофа произошла на энергетическом объекте, то тематика таких аварий интересна и энергетикам.

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

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

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

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

Характерные жалобы абонентов – скорость ниже тарифа, и возникают регулярные «замирания» при работе в интернете, что выражается долгим открыванием страниц в браузере, прерываниями видео, потерей связи с игровыми серверами и т.д. Данное поведение носит нерегулярный характер, а наиболее часто возникает в часы наибольшей пользовательской активности примерно с 18:00 до 23:00 в зависимости от города.

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

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



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

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

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

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



Так и в ситуации с консолями MMC. Вы создаёте для себя «пульт управления» и при определённых ситуациях нажимаете на нужные «кнопки».
Публикация рассчитана на системных администраторов, желающих познакомиться с методом создания консолей управления Windows, путём использования mmc.exe.

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

Представим себе некоего «абстрактного» разработчика/программиста который создаёт программный продукт. Будем рассматривать его не как живого человека, а как некоторое облако знаний, накопившихся в его голове за годы работы. Наш абстрактный программист — профессионал практически во всех областях, это наш идеал к которому нужно стремиться. Недостижимый идеал! Но как сформировать облако знаний в своей голове? В каком порядке эти знания должны поступать? Как эти знания классифицировать?

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

TL;DR. Мы пытались охватить многое, поэтому статья получилась пугающе объемной. Но, надеюсь, познавательной. А еще под нее ностальгировать можно.

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

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

2 года назад я написал статью о классификации знаний в области программирования. Это было на волне интереса и моей активной деятельности по самообразованию в компьютерных науках. Написал статью и забыл о ней. Публиковать на Хабре не собирался. В конце концов, она базируется на моем личном опыте и знаних, которые могут оказаться весьма субъективны.

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

Но прежде, чем «запустить» материал, еще небольшое отступление. О том, почему вообще я все это писал. Дело в том, что у нас в странах бывшего СССР с образованием в области IT очень туго. С одной стороны нет программ обучения, которые подготовят специалистов на должном уровне (наверное, за очень редкими исключениями, которые можно отнести к погрешности). С другой стороны, из-за широких возможностей самообразования, программисты и не спешат учиться в ВУЗах — все стремятся начать практиковать как можно раньше. Часто изучается только одно направление (например PHP+Mysql — самое популярное) и в бой. Причем, на этом все заканчивается. В итоге у нас огромное количество программистов, которые и базовых вещей не знают. Отсюда вытекают проблемы с качеством кода, и с эффекивностью алгоритмов, с велосипедированием.

Но программирование — это полноценная область знаний, которая требует в том числе и инженерной подготовки. Точно так же, как строительство или телекоммуникации. Да, построить дом (особняк) можно своими руками и без образования. А поднять большинство сайтов можно прочитав пару книг по PHP и HTML. Но многоэтажку без специальной подготовки не построишь, как и Гугл не напишешь, не зная основ.

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

Поехали.

Microsoft выпустила предварительную версию Visual studio 2015 и .Net 4.6 для разработчиков. В новом C# 6.0 несколько новых возможностей, которые могут облегчить кодинг.

В этой статье рассмотрены новые возможности языка C# 6.0. Скачать новую VS можно по ссылке:
Microsoft Visual Studio Ultimate 2015 Preview

Инициализация свойств со значениями

В C# 6.0 мы можем инициализировать свойства со значениями, написав справа от них их значение. Это поможет избежать ошибки с null и пустыми значениями свойства.

Раньше:

public int Id { get; set; }
public string FirstName { get; set; }

Теперь:

public int Id { get; set; } = 1001;
public string FirstName { get; set; } = "Srinivas";

Pipe — что это?

Pipe (конвеер) – это однонаправленный канал межпроцессного взаимодействия. Термин был придуман Дугласом Макилроем для командной оболочки Unix и назван по аналогии с трубопроводом. Конвейеры чаще всего используются в shell-скриптах для связи нескольких команд путем перенаправления вывода одной команды (stdout) на вход (stdin) последующей, используя символ конвеера ‘|’:

cmd1 | cmd2 | .... | cmdN

Например:

$ grep -i “error” ./log | wc -l
43

grep выполняет регистронезависимый поиск строки “error” в файле log, но результат поиска не выводится на экран, а перенаправляется на вход (stdin) команды wc, которая в свою очередь выполняет подсчет количества строк.

Логика

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

Размер буфера начиная с ядра версии 2.6.11 составляет 65536 байт (64Кб) и равен странице памяти в более старых ядрах. При попытке чтения из пустого буфера процесс чтения блокируется до появления данных. Аналогично при попытке записи в заполненный буфер процесс записи будет заблокирован до освобождения необходимого места.
Важно, что несмотря на то, что конвейер оперирует файловыми дескрипторами потоков ввода/вывода, все операции выполняются в памяти, без нагрузки на диск.
Вся информация, приведенная ниже, касается оболочки bash-4.2 и ядра 3.10.10.

Простой дебаг

Утилита strace позволяет отследить системные вызовы в процессе выполнения программы:

$ strace -f bash -c ‘/bin/echo foo | grep bar’
....
getpid() = 13726                   <– PID основного процесса
...
pipe([3,  4])                       <– системный вызов для создания конвеера
....
clone(....) = 13727                <– подпроцесс для первой команды конвеера (echo)
...
[pid 13727] execve("/bin/echo",  ["/bin/echo",  "foo"],  [/* 61 vars */] 
.....
[pid 13726] clone(....) = 13728    <– подпроцесс для второй команды (grep) создается так же основным процессом
...
[pid 13728] stat("/home/aikikode/bin/grep",   
...

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

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

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

Год только начинается, так что давайте посмотрим, что язык С++ ожидает в 2015-м, как мы уже делали это в 2013-м и 2014-м.

Прошлый год принёс много изменений, главным из которых, безусловно, является стандарт С++14. Что важно, С++14 сегодня существует не только в виде стандарта, но и частично поддерживается GCC и Clang. Visual Studio также поддерживает некоторые (хотя и далеко не все) возможности С++14 и почти все (хотя опять таки не 100%) возможности С++11. Компилятор от Intel стал совместим с С++11 полностью. Таким образом, современные стандарты С++ доступны под все платформы — было бы только желание их использовать!

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

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

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

При ООП подходе программист составляет новые объекты и расширяет существующие путём добавления к ним методов.

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

При ФП подходе программист пишет новые функции.

Переводя свои приложения на платформу 8.1, я обнаружил, что это довольно несложное занятие, которое не требует особых усилий.
После перевода зачастую возникают типовые предупреждения, возникшие в результате несоответствия платформ. Разумеется, эти предупреждения желательно исправить.
Рассмотрим самые популярные исправления?