Провели нам в офис вторую линию интернета. Так как основная (дальше я буду называть её первой) хоть и хороша по-скорости, но ограничена по трафику. Вторая немного медленнее, но безлимитна. Днём вторая линия почти свободна и выдаёт хорошую скорость, поэтому и была выбрана основной для рабочего дня. К вечеру скорость сильно падает из-за нагрузки на канал и приходится переключаться на первую. Так бывает не всегда, но достаточно часто.
Потому возник вопрос в переключении линий. Роутером у нас трудится обычный компьютер с FreeBSD на борту. Городить хитрую логику проверки скорости канала смысла не было, к тому же нужна была индикация активного подключения. Настроив переключение каналов на консольные команды с помощью sh скриптов в папке /bin, мы столкнулись с двумя проблемами:

1. Доступ к консоли только у админа, а он не всегда на месте, да и дёргать ради переключения каналов тоже не очень удобно.
2. Нет индикации актвного, на данный момент, подключения.
Поэтому было принято решение сделать переключатель физическим и снабдить индикаторами.

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

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



Курс посвящён дизайнерским принципам работы со сложными данными и знакомит слушателей с бибилиотекой D3.js — самым мощным и гибким инструментом создания интерактивных визуализаций. Курс состоит из 6 лекций и 6 практических заданий, каждое из которых позволяет применить и закрепить теоретический материал.

Доброго времени суток, многоуважаемый %USERNAME%. Меня зовут Голованов Сергей, и я всё еще являюсь ведущим вирусным аналитиком в «Лаборатории Касперского». Я понимаю, что название этого поста в корпоративном блоге компании может вызвать смех, грусть, а у некоторых даже эпилептический припадок, но дайте мне всё объяснить.

Я понимаю, что для всех батники выглядят как нечто очень простое и со времен AUTOEXEC.BAT уже практически забытое, в то же время эксплойты, если вы конечно не профессиональный исследователь уязвимостей, выглядят очень сложно и практически неправдоподобно, особенно для некоторых разработчиков. Но! В данном посте я постараюсь перевернуть эти представления и рассказать, что всё как будто наоборот. Батники чуть легче и сильнее по функционалу brainfuck'а, а эксплойты не страшнее сортировки пузырьком на basic'е.


(Осторожно! 3 МБ иллюстрированного потока сознания и куча скриптов)

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

"type":
[
	{
		"id": 1,
		"type": "one",
	},
	{
		"id": 2,
		"type": "two",
	},
	{
		"id": 6,
		"type": "three",
	}
]

Но в тоже время в кодe хочется использовать структуры типа:

enum Type
{
	one,
	two,
	three
};

Далее в теле статьи будут приведены несколько вариантов решения.

Данная статья для тех, кто еще не знает, нужно или ему высшее образование. Я ни в коем случае не пытаюсь сказать, что оно не нужно. Каждый сам для себя делает выводы. И возможно так не во всех ВУЗах, как было у меня.

О поступлении

В далеком 2010 году поступила я в ВУЗ. Моих несчастных 166 баллов (по 3 предметам) хватило только на МГУПИ. Такое количество баллов из-за того, что в ВУЗ пошла после 2-х курсов колледжа и вечерней школы, и так вышло, что на подготовку к ЕГЭ по всем 3 предметам у меня было что-то около 2 недель в перемешку с сессией колледжа.

Мама хотела, чтобы я училась в МГТУ СТАНКИН, и поэтому туда сразу отдали оригинал аттестата. Но моих баллов в первую волну на бюджет не хватало. Было несколько попыток забрать аттестат, но приемка морозилась, убеждая подождать 2-й волны. В итоге, почти с боем, аттестат отдали.

Личные фото некоторых знаменитостей, включая Дженнифер Лоуренс, Кейт Аптон и Ариана Гранде были опубликованы анонимным хакером на сайте 4Chan. Судя по всему, утечки стали возможными благодаря взлому аккаунтов от облачного хранилища Apple iCloud, в которое автоматически копируется информация со всех устройств Apple, о чем большинство пользователей даже не задумываются.

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

Пресс-секретарь Дженнифер Лоуренс сделал заявление, подтверждающее, что фотографии являются подлинными:

Предисловие

Был обычный вечер. Заняться было нечем, а скоротать время до сна каким-то образом надо было.
Решил я почистить свой внешний HDD от хлама, а заодно и проверить, есть ли новая прошивка на любимый карман Zalman VE-300. Зайдя на сайт Zalman, я как раз такую и обнаружил. Пока прошивка скачивалась через невероятно медленный EDGE, я просматривал changelog. Мой взор привлекла такая строчка:
Support VHD of MS / VMDK of VMWare which is virtual Hard disk file (Still not support for Dynamic)

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

Многие опытные пользователи github-а знают, что отнюдь не для всего обязательно нужно использовать командную строку. Все это так.

Здесь я собрал несколько рецептов, используя которые, вы сможете без единой команды git, скопировать себе репозиторий, создать там вспомогательную ветку, в ней что-то отредактировать, добавить/удалить файлы/папки, сделать пулл-реквест в оригинальный репозиторий. А по истечению какого-то времени, когда в оригинальном репозитории накопятся изменения не отраженные в нашей копии — синхронизировать эти два репозитория — причем тоже без единой git-команды.

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

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

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

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

Принципы условно сгруппированы в три группы: принципы принятия решений; принципы, направленные на повышение качества кода; принципы, направленные на повышение производительности кода.

• Принятие решений
  • Любое техническое решение должно быть обосновано
  • Ответственность за принятое решение всегда лежит на том или тех, кто принял данное решение
  • При принятии технических решений необходимо учитывать их действие во времени и их соответствие потребностям бизнеса
  • Одним из основных критериев при принятии технических и иных решений должна быть их наибольшая эффективность
  • Смело отступать от правил, методологий, шаблонов и прочих ограничений, если эффект от такого отступления превышает возможные потери (Special cases aren't special enough to break the rules, although practicality beats purity)
  • При необходимости сделать работающее, но, возможно, не наилучшее, решение сразу, а позднее улучшить его (Now is better than never, although never is often better than *right* now)
  • Если сложно выбрать между двумя альтернативными техническими решениями, то нужно выбрать любое и двигаться с ним дальше, когда появится больше инфорации, то можно будет сделать рефакторинг, если решение оказалось неоптимальным
  • Гибкость технических решений крайне желательна, а универсальность не обязательна
• Качество исходного кода
  • Качество кода следует оптимизировать на базе сформированной системы критериев, сбалансированной по отношению к затратам в краткосрочном и долгосрочном периодах
  • Писать оптимальный код сразу, если это не увеличивает его сложность и сроки разработки (Beautiful is better than ugly)
  • Самодокументируемый код имеет приоритет над хорошо прокомментированным (Beautiful is better than ugly)
  • Писать TODO и FIXME в коде
  • Давать переменным, функциям, методам, классам и другим объектам исходного кода имена точно отражающие их назначение, несмотря на увеличение длины названий (Explicit is better than implicit)
  • Меньшее число строк и объем кода предпочтительнее, при сохранении прежней читабельности кода (Simple is better than complex)
  • Применять инспекцию кода (code review) как инструмент обнаружения ошибок, выравнивания стиля разработки, знакомства с чужим кодом и обучения в команде
  • Применять повторное использование своего и чужого кода
  • Использовать специализированные библиотеки для решения конкретных задач, вместо разработки своего аналогичного кода
• Производительность
  • Производительность разработки кода имеет приоритет над производительностью исполнения кода
  • Оптимизация производительности исполнения кода должна быть обоснована соответствующей потребностью
  • Оптимизация производительности исполнения кода должна выполняться за счет устранения наиболее серьезных узких мест
  • В первую очередь должны быть использованы наиболее эффективные методы оптимизации производительности исполнения кода

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

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

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

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

Итак, где и когда [х] впервые попал в лексикон интерфейсов?

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


^{Перевод, оригинал}

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

• английские слова (например, «idea critic happy chinese»);
• русские слова (например, «порошок земля нуль платье»);
• транслитерированные русские слова (например, «vysota razum bumazhka razmer»).

Код и списки слов на GitHub.

Добрый день, уважаемые читатели.

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

У меня тут грустный юбилей. Нет, я не отмечаю первый год в завязке или десятилетие со дня первого развода. Все куда проще. Но в каком-то смысле не менее драматично. Недавно я профинансировал на «Кикстартере» свой сотый проект.



За три года я потратил на краудфандинг примерно 30 000 долларов. Наверное, это дает мне некоторое право считать себя ветераном. И как любому нормальному ветерану, мне хочется немного побрюзжать. Хотя, боюсь, скорее у меня получится крик души.

Впервые попав в 2011 году на «Кикстартер», я был окрылен идеей краудфандинга. Работая в Panasonic, я не понаслышке знал, как мало транснациональные корпорации предпринимают усилий, чтобы сделать что-то действительное инновационное. А тут я увидел, что благодаря краундфандингу любой талантливый технарь мог вдохновить своей идеей бэкеров, собрать денег, основать компанию и дать миру что-то по-настоящему новое.

Я начал вкладывать деньги в перспективные проекты. Просиживал на «Кикстартере» часами. Искал классные инновации. Обсуждал разные безумные идеи. Тратил деньги и ждал посылок, словно ребенок — новогодних подарков. Из всего этого безумства и родился интернет-магазин MadRobots. Возможность дать денег авторам уникального устройства, которое я вскоре смогу продавать в России через свой магазин, казалась мне вдохновляющей.

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

«Как она могла так поступить со мной?» — спрашивал я себя. Каждый день. Все время.

В 2011 году, когда еще были популярны градиенты, а Ай-ОС иконки задавали направление в дизайне и люди пользовались дезодорантами, я был в депрессии из-за своего развода.

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

* * * * *

Как-то раз, я пришел в офис и взглянул на свой монитор. Все было классно, пока я не увидел это сообщение:

Ваш пароль устарел.
Кликните на кнопку «Изменить пароль», чтобы изменить пароль.

Да ладно! А я-то думал кнопка «Изменить пароль» предназначена для чего-то другого.

Я прочитал это дурацкое сообщение про себя голосом ворчливого старика: «Чертов пароль устарел».

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

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

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

* * * * *

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

Вскоре, немного успокоившись, я вспомнил про метод, который слышал от своего бывшего начальника Расмуса. Он объединил список дел с паролями. А я решил использовать расширенный вариант этого метода.

Я решил использовать пароль, чтобы изменить свою жизнь.

Винт Серф смотрит в будущее Интернета

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

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

Но на днях вышел интересный ролик, созданный Google с участием Винта Серфа. В ролике, весьма красочном, кстати, рассказывается о том, что представляет собой ICANN, как работает эта организация и подконтрольная ей доменная/серверная инфраструктура, и зачем все это нужно.

К сожалению, давно пропали топики-ссылки, но иногда бывают крайне занимательные вещи из первых рук. Рекомендую пост Анатолия Воробея (работает разработчиком в «Гугле»).

В видеоформате MP4 (стандарт MPEG-4) есть возможность записать «время создания» любого потока данных, с помощью специальной метки. Значение этой метки в стандарте: количество секунд, прошедших с 1 января 1904 года, или так называемое «время по эпохе макинтоша», потому что маки первыми стали использовать такой отсчет времени. Меж тем, в современных серверах намного проще иметь дело с «временем по эпохе Юникса», а именно количеством секунд, прошедших с 1 января 1970 года. В результате этого, во множестве программ, которые работают на Линуксе или других юниксовских операционных системах, есть кусок кода, который выглядит примерно так:

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

Чему равна константа «разница между временем по юниксу и временем по макинтошу»? Она равна в точности числу секунд, прошедших между 1 января 1904 и 1 января 1970. Это 66 лет, из которых 17 были високосными (проверьте, если не доверяете мне). Всего дней получается: 66 * 365 + 17 = 24 107, а секунд, учитывая 86 400 секунд в сутках: 24 107 * 86 400 = 2 082 844 800. Это правильное значение константы.

Разработчики MicroXWin — Xorg сервера режима ядра — вовсю заняты своим новым детищем VolksPC.
VolksPC это компьютер, на котором можно запустить Android и Debian одновременно, на полной скорости железа, и переключаться между ними горячей клавишей. Никакой эмуляции, никаких VNC, никакой заморозки состояний: две полноценные системы работают одновременно.
Системы также полностью независимы друг от друга. Вы можете выгрузить Android и пользоваться только Debian, и наоборот.



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

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

Логически вся книга планируется из трех разделов-частей:
1) Интервью с программистами, админами, т.д. – прямая речь;
2) Интервью об информационных технологиях и интернете, их влиянии на общество – профессионалы, не являющиеся непосредственно разработчиками, но которые «варятся» в этой кухне, расскажут об их, подчас, странной субкультуре и технологиях;
3) Случаи из жизни программистов и айтишников – несколько ярких и живых примеров, полуюмористических (или поучительных) историй, основанных на реальных фактах и событиях (в стиле Веллера и его «Легенд Невского проспекта»).

На Западе книги подобного плана весьма популярны: достаточно вспомнить «Coders at Work» Сейбела, у нас подобный жанр пока ещё только приживается.
В связи с этим хочется установить предварительную обратную связь с будущими читателями. Любопытна ли будет вам такая книга? Какие вопросы и темы было бы интересно затронуть? Может быть, вы захотите предложить нам ещё каких-то интересных собеседников?

Ниже под катом можно посмотреть список интервьюируемых и краткую аннотацию по теме беседы.

Это пост про ограничения старых видеоигр. Сам я под NES никогда не программировал, но с архитектурой поверхностно познакомился. Теперь я не могу играть в игры для NES, не задумываясь, как же они устроены. Иногда это на столько вызывает восхищение, что невольно забываешь про саму игру. «Чему же там восхищаться?», — скажете вы. Да просто укладываться во все ограничения NES, но при этом делать игру красивой, — это действительно целое искусство.

Сейчас я постараюсь рассказать об этом вам, максимально всё упростив.