В последнее время я видел мало действительно хорошего кода, много посредственного и очень много — плохого. (Много того, что я писал раньше — особенно, когда я только начинал — относится к последним, увы.) Читая случайные статьи в интернете и профессиональные книги, я пришел к выводу, что писать хороший код — легко. Невероятно трудно, но в то же время легко. На самом деле, это настолько просто, что сводится к трем правилам.

Сегодня мы представляем долгожданный клиент Яндекс.Диска для Linux. Можно было бы даже сказать «специально для Хабрахабра», так как ни одно упоминание Диска здесь не обходилось без вопросов о клиенте для Линукса.

У него есть вся основная функциональность, которая есть у клиентов для OS X и Windows, и даже больше (симлинки!), и одна особенность — он консольный.



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

Прелюдия

Я давно следил на ХабраХабр за проектом Raspberry Pi и твердо решил заполучить свой мини-компьютер. Когда начался предзаказ, я воспользовался им практически сразу, однако только 17 июня 2012 года мне на Email пришло сообщение от RSComponents.Com о возможности заказа моего экземпляра Raspberry Pi. Итого прошло около месяца с момента предзаказа.

В этот же день я создал заказ (кстати, в то время уже можно было заказать «официально» в Российскую Федерацию) и стал ждать свою «малину». Информационное письмо обещало отгрузку в течение максимум 6 недель, но в этот срок я так и не получил свою плату. Во время звонка в московское представительство RS, менеджер фирма дал понять, что поставки скоро будут, но когда — неизвестно.

17 августа мне на email пришло сообщение от сотрудницы Московского RS, что моя плата доставлена в офис и ее можно забирать (т.к. заказать из RS с доставкой на дом нельзя, потому что DHL не доставляет посылки частным лицам). Собственно говоря, в этот же день я и получил свой компьютер Raspberry Pi!

Доброго времени чтения, уважаемые участники habrahabr.ru

Идея туннельного моделирования базируется на объединении двух идей
— модернизированной девятиуровневой модели взаимодействия открытых систем (http://habrahabr.ru/post/176249/)
и
— цикла Деминга Plan-Do-Check-Act, который входит в стандарт ГОСТ Р ИСО 9001.

Как сообщается на сайте «Почты России», массированной спам-атаке подвергается сайт Роскомнадзора.

«Спланированной акцией спамеров», по мнению ФГУП, является отправка жалоб на работу почтовой сети. Если ранее сайт Роскомнадзора получал не более десятка таких заявлений в день, то с середины марта в службу ежедневно приходит до 1000 обращений клиентов интернет-магазинов о проблемах с доставкой покупок.

К счастью «Почта России» быстро отреагировала на провокацию и уже готовит заявление в МВД:

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

Мы продолжаем выкладывать в общий доступ лекции Алексея Брагина, который теперь читает авторский курс лекций об операционных системах в МГТУ им. Баумана.

Прошу принять во внимание, что это пилотный проект. А так конструктивная критика приветствуется, пожелания принимаются.
По просьбам трудящихся качество звука значительно улучшено!
Но смотреть, все равно лучше в HD

Месяц назад здесь было объявлено, что Алексей Брагин теперь читает авторский курс лекций об операционных системах. С тех пор Алексей успел провести уже несколько занятий, которые были записаны на видео. Думаю, вполне логичным шагом будет поделиться этими записями с сообществом. Что нам стоит поступить так же как, к примеру, сделал MIT?

Прошу принять во внимание, что это пилотный проект. А так конструктивная критика приветствуется, пожелания принимаются.
Приносим извинения за качество звука, смотреть лучше в HD и погромче.

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

Регулярные выражения (РВ) это, по существу, крошечный язык программирования, встроенный в Python и доступный при помощи модуля re. Используя его, вы указывается правила для множества возможных строк, которые вы хотите проверить; это множество может содержать английские фразы, или адреса электронной почты, или TeX команды, или все что угодно. С помощью РВ вы можете задавать вопросы, такие как «Соответствует ли эта строка шаблону?», или «Совпадает ли шаблон где-нибудь с этой строкой?». Вы можете также использовать регулярные выражения, чтобы изменить строку или разбить ее на части различными способами.

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

Шла четвёртая неделя тяжёлых боёв с Play! Framework 2.1 + Java. Победа неумолимо приближалась, но до полной капитуляции было далеко.
После обнадёживающих новостей про развитие Play! 2.1, например в LinkedIn, было решено попробовать его в одном новом проекте. Испытать его, так сказать, в деле. Что из этого получилось? Я бы сказал, что это была небольшая война между мной и Play! 2.1. Почему? Подробности под катом, а для нетерпеливых:

Краткий вывод

Для штурма надо было брать секретное оружие под кодовым названием Scala. Если встать лицом к лицу с Play! Framework 2.1 и крикнуть со всей силы: «Ты есть Scala-фреймворк!», то он испугается такой прямоты и скромно откроет свои двери в мир больших возможностей.
«Не знаете Scala?» — «Используйте Play 1.2».
«Хорошо разбираетесь в Scala?» — «Обязательно попробуйте Play 2.1. Но всё равно запаситесь терпением».

Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.

Доброго времени суток, уважаемое хабросообщество!
Недавно в универе мне была поставлена задача создать сервис смс-рассылки уведомлений старостами (деканатом и прочими) своим группам.
Основные требования к сервису были следующими:
— Сервис должен быть многопользовательским (старост более 1) с возможностью одновременной обработки запросов
— Не должен быть привязан к online сервисам рассылки (дабы не утекли базы пользователей)
— Должен быть достаточно легким и мобильным
— Максимально малозатратным
— Должен использовать только открытое программное обеспечение
— Должен обеспечивать отправку уведомлений, даже если у отправляющей стороны нет доступа к Интернету и/или компьютеру. (т.е. не только отправлять, но и принимать входящие смс сообщения от старост + определять от кого конкретно они поступили и делать рассылку по их группам)

Как удалось это реализовать — смотрите под катом.

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.

В продолжение темы, почему иногда нужно делать свой велосипед, хочу дополнить и расширить эти мысли причинами, по которым этого делать не стоит.

Причина 1. Вы не знаете, как такие велосипеды устроены

Посмотрите внимательно на предыдущий топик. Генри Форд — с детства изучал технику. Его сестра как-то сказала, что в детстве любую игрушку старались спрятать от него, потому что он ее тотчас разберет на винтики. Работал инженером в «Электрической компании Эдисона», был совладельцем «Детройтской автомобильной компании». Он точно знал, что это такое — автомобиль. Он точно знал технические нюансы. Он точно знал, что черная краска сохнет два дня, а любая другая — две недели! Ну не из-за прихоти же он однажды сказал, что автомобиль будет только черным.

Игорь Сысоев, прежде чем делать свой nginx, уже имел «достаточно неплохой опыт работы с Apache — и как у системного администратора, и как у программиста».

Знаете ли вы, что вам предстоит на пути создания своего велосипеда? Или просто готовы окунуться с головой, не проверив глубину водоема?

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

Думаю, многие сталкивались с такой проблемой. Провайдер предоставляет услугу IPTV, не WebTV по протоколу HTTP, а классическое IPTV по протоколу UDP multicast. Есть телевизор с Ethernet-портом или медиаплеер, с поддержкой данного сервиса. На маршрутизаторе включаем функцию Multicast Stream (или IPTV multicast). Подключаем к нему витой парой свой ТВ или медиаплеер, подгружаем файл плейлиста в формате M3U или XML и наслаждаемся просмотром ТВ-программ в HD качестве.

Но у меня, как видимо и у многих читателей, возникло желание избавится от не нужных проводов. Тем более, есть множество смартфонов, планшетов и других гаджетов, не имеющих физической возможности подключения проводов. Да и просто, Wi-Fi – это удобней, как говорится «дальше, больше, лучше».

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

Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

Мы всё обсудили? Нет? Что ещё?

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.

Продолжение перевода здесь

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

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