Новые интернет-провайдеры появляются буквально каждый день, и 12 декабря 2017 года не было исключением. Новичок в экосистеме междоменной маршрутизации, AS39523 (DV-LINK-AS), начала анонсировать собственное адресное пространство (один префикс), добавив к нему в то же время еще 80 чужих префиксов, принадлежащих как российским, так и международным контент-провайдерам, таким как Google, Facebook, Mail.ru, Vkontakte и многих других.


Инцидент длился более 2-х часов, начавшись в 4:44 по UTC с пиком в 80 префиксов, закончившись в 7:19 с еще одним пиком в районе 7:04 UTC.

Вот какие заголовки мелькали в финансовых новостях в последние недели:

«Цена биткоина наконец дошла до 10 000 $!» — The Economist, 28 ноября 2017
«Биткоин перешагнул рубеж в 10 000 $!» — CNBC, 28 ноября 2017 года
«БИТКОИН ВЗЛЕТЕЛ ВЫШЕ 11 000 $!» — The Guardian, 29 ноября 2017 года


Не успели эти известия толком перекипеть на новостных порталах, как буквально через сутки цена уже выросла до $11,500. К моменту, когда вышли заметки про одиннадцать тысяч, он уже успел упасть до девяти. А потом, пока журналисты лихорадочно дописывали последние строчки про «обвал биткоина», снова вернулся на уровень 11 000 $ за BTC.

И это не первый такой случай.

Мы уже сталкивались с чем-то подобным в 2013 году. Когда стоимость биткоина подошла к отметке в 1000 $, пресса подняла шумиху, что привело к образованию «пузыря». В январе 2013 биткоин уходил примерно за 15 $, к апрелю цена подскочила до 266 $, а затем обвалилась до 50 $. К ноябрю она превысила 1 200$, достигнув максимума в 1 242 $ на Mt.Gox. За тот год биткоин вырос почти в сто раз – это на порядок больше, чем десятикратный подъем, через который он прошел в 2017 году.

Графики выглядят почти одинаково, а новостные заголовки вообще слово в слово. Просто припишите нолик.

Пресса любит такие вещи, потому что люди читают их с большим интересом. Истории о том, как кто-то купил старый компьютер за 25 баксов и обнаружил на нем 5 000 биткоинов, или случайно выбросил жесткий диск с 7 500 биткоинами и долго искал его на свалке, или отдал 10 000 биткоинов за две пиццы, раздувают ажиотаж и приносят деньги.

Согласно данным аналитического агентства «АВТОСТАТ», по итогам октября 2017 года объем рынка легковых автомобилей с пробегом в России составил 473 тыс. единиц, а по итогам 10 месяцев 2017 года — около 4,4 млн единиц, что на 1,5% больше, чем год назад.

Источник: www.autostat.ru/press-releases/32145

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

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

Здравствуйте всем!

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

Удобочитаемый синтаксис, прост в обучении, высокоуровневый язык, Объектно-Ориентированый язык программирования (ООП), мощный, интерактивный режим, масса библиотек. Множество иных плюсов… И это всё в одном языке.
Для начала окунёмся в возможности и узнаем, что же умеет Python?

Аргумент -9 (или KILL) для команды kill следует использовать в POSIX-совместимых системах только в случае крайней необходимости. Почему? Сигнал KILL не может быть обработан процессом. Это означает, что после завершения процесса с помощью kill -9, дочерние процессы останутся в памяти и станут «осиротевшими» (orphaned), файловая система окажется засорена временными файлами, сегменты совместно используемой памяти — активными, сокеты — зависшими, а функция atexit(3) вообще не будет выполнена. В результате есть риск столкнуться с неожиданными и сложными для отладки проблемами.

Что такое НОД, все знают еще со школы. Для тех, кто подзабыл, напомню: НОД — наибольший общий делитель, делящий два целых числа без остатка. Например, НОД чисел 100 и 45 равен 5, а НОД чисел 17 и 7 равен 1. Существует несколько различных алгоритмов поиска этого числа. Однако, несмотря на то, что это достаточно простые алгоритмы, часто совершают одну маленькую, но очень существенную ошибку.

Качественная документация – неотъемлемая часть успешного программного продукта. Создание полного и понятного описания всех функций и возможностей программы и программного компонента требует немало сил и терпения. В данной статье я рассмотрю некоторые практические аспекты создания документации для .NET компонентов.

Предположим, что у нас готова или почти готова некоторая .NET библиотека для разработчиков (они же конечные пользователи). API библиотеки безупречен, количество багов впечатляюще мало, да и вообще это не библиотека, а просто кладезь совершенного кода. Дело за малым – объяснить пользователям, как работать с этим замечательным продуктом.

Есть разные подходы к написанию документации. Некоторые команды предпочитают начинать создание документации в момент начала создания продукта. Другие откладывают написание мануалов на окончание работ. В некоторых командах документацию пишут специальные люди, которые ходят от разработчика к разработчику и от менеджера к менеджеру, аккумулируя знания о продукте. Во многих небольших командах таких специальных людей нет, а потому документацию часто пишет разработчик или разработчики. Кто-то использует сторонние средства вроде Help & Manual, в которых, как в заправском текстовом редакторе, можно создавать очень сложную верстку и на выходе получать документацию в многообразии форматов. Многие используют другой подход, широко пропагандируемый в последнее время – написание документации прямо в коде программы/библиотеки.

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

Приветствую, хабра-дотнетчики!
Сегодня речь пойдет об одной интересной и полезной возможности языка С#, которая поможет нам в документировании кода. Она называется «XML документация» или «Документирующие комментарии XML». Это такие специальные теги XML, которые содержаться в комментариях и описывают свойства или методы в конкретном файле. Так вот, есть по крайней мере три веских причины, почему всегда следует заполнять XML комментарии.

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

На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:

• сделать бэкап сервера;
• восстановить бэкап на другом железе.

Гугление не дало внятных ответов, как это сделать, пришлось собирать информацию кусками и пробовать. Всякие acronis’ы отбросил сразу, ибо не интересно.

Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги :)

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

Почему голову называют «башкой» и как это связано с командной оболочкой bash? А ведь если внимательно присмотреться, то окажется много общего. Процессы, ежесекундно происходящие в нашем мозгу до боли напоминают экран команды top — утилиты *nix, динамически отображающей потребление ресурсов системы.

Вы загружены работой и вдруг мимо вашего стола продефилировала новая сотрудница отдела разработки. Спящий высокоприоритетный системный демон резервного ДНК-копирования моментально захватил практически все ресурсы, текущий пользовательский процесс работы над проектом отброшен как niceless в «прекрасное далёко» оперативной памяти и жалобно обиженно пищит… Неимоверными усилиями вам удается перехватить управление и вернуться к работе, справедливость восстановлена. Уфф!

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

1. На каждый чих приходилось сто раз переключать раскладку, чтобы корректно ввести пару команд и вернуться обратно. Например, замена буквы-опечатки в только что написанном слове, выливалось в: switch → добраться до буквы, нажать r → switch → [нужная буква] → switch → A → [пишем дальше]. Ад!
2. Штатный spell checker букву «ё» не любил и любое слово с её участием предлагал заменить на аналог через «е». А я ё люблю, меня это расстраивало.

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

LaTeX годится не только для составления всевозможной документации, но и для верстки качественных презентаций. При помощи пакета beamer можно создавать презентации, ничуть не уступающие презентациям PowerPoint или Impress.

Уже давно я слышал об инструменте для автоматизации сборки проекта — Ant, но как-то не мог найти ему реального применения в проектах на PHP. Компилить вроде ничего не надо, внешние библиотеки вполне можно подключить через svn:externals, оставались только тесты, которые свободно выполнялись через $ phpunit AllTests.php, да перенос изменений на рабочий сервер (svn export + небольшой самописный скрипт). Даже достаточно хорошая статья об использовании ant в eclipse не подвигла меня на использование сего инструмента, да еще и build файлы писать не хотелось…

Вобщем все как всегда. Какая-то подобная штука вроде бы и не помешала бы, но все и так хорошо работало и лень было изучать псевдопомогающую технологию. Так было до тех пор, пока я не познакомился с Java…

Привет, Хабр, давно не виделись. В этом посте мне хотелось бы рассказать о таком относительно новом понятии в машинном обучении, как transfer learning. Так как я не нашел какого-либо устоявшегося перевода этого термина, то и в названии поста фигурирует хоть и другой, но близкий по смыслу термин, который как бы является биологической предпосылкой к формализации теории передачи знаний от одной модели к другой. Итак, план такой: для начала рассмотрим биологические предпосылки; после коснемся отличия transfer learning от очень похожей идеи предобучения глубокой нейронной сети; а в конце обсудим реальную задачу семантического хеширования изображений. Для этого мы не будем скромничать и возьмем глубокую (19 слоев) сверточную нейросеть победителей конкурса imagenet 2014 года в разделе «локализация и классификация» (Visual Geometry Group, University of Oxford), сделаем ей небольшую трепанацию, извлечем часть слоев и используем их в своих целях. Поехали.

К написанию сей заметки меня сподвигло то, что я устал делать развёрнутые замечания на эту тему в комментариях к статьям, где в качестве части инструкции по сборке и настройке чего-либо для конкретного дистра предлагают выполнить make install.

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

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

Привет Хабр! Летом мы переводили цикл статей про Bash-скрипты — судя по отклику, статьи оказались для вас полезными. И, по многочисленным просьбам, мы решили сделать PDF-версию перевода.



Подробности под катом.

У вас есть старенький (или не очень) компьютер с двумя сетевыми картами? Вам надоела реклама и лишние телодвижения для обхода блокировок? Вы не хотите с этим мириться? Тогда добро пожаловать под кат.

Касательно Upstart

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

Я это сказал, но я не могу сказать, что в целом согласен с подходом используемом в Upstart. Но для начала, чуть больше об Upstart.

LibreOffice в корпоративном секторе — к старту готов

Есть на Хабре такая хорошая статья за авторством frozer, в которой рассматривается развертывание (с помощью Active Directory) и использование LibreOffice (LO) в корпоративной среде.

Единственный минус статьи — только теоретический подход. Т.е. автор описывает что можно сделать для корпоративной интеграции LO, но практическая часть отсутствует, как таковая.

Я пытался узнать секреты и получить советы на официальном русскоязычном форуме LO, и вот что получил в ответ:

Есть самый эффективный путь.
Скомпильте из иисходников под себя. Или заплатите тому, кто это сделает.

Это явно не тот метод. В интернете информации тоже очень мало, поэтому будем восполнять пробелы.

Инструкция — под катом.