Думаю, многим интересно (хотя бы из любопытства), как именно они используют свой компьютер: самые нажимаемые кнопки, пройденное мышью расстояние, среднее время работы и другую информацию. В этой статье я расскажу один из вариантов того, как можно собрать такую информацию и затем представить её в виде интерактивных графиков. Все описанные действия производились на ноутбуке с ОС Debian Wheezy, Python 2.7.3, R 2.15.

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

there is no way to find what queries are now cached

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

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

Удивительно, что человек проработал 10 лет менеджером в ИТ, а у него нет инструкций и документации, что же должен делать менеджер в течении дня. Так может учебник «Основы менеджмента» хотя бы стоило прочитать. А вообще-то менеджмент — это такая научная специальность отдельная… Тысячи научных специалистов трудятся в ней, какие-то теории управления придумывают, книги издают, исследования проводят, те же agile-методы (scrum и другие) развивают. Может там следует инструкции поискать? Ах да, там же одна «водичка» написана, а у нас тут реальные проекты, да еще и работники какие-то неправильные, ни под одну теорию менеджмента не вписываются.

Сегодня мы предлагаем вашему вниманию отрывок из книги Сергея Тарасова «Дефрагментация мозга. Софтостроение изнутри», которая готовится к выходу в нашем издательстве.

Сокрытие базы данных или как скрестить ёжа с ужом

Упомянув один из крупнейших столпов современного софтостроения — мир ООП, нельзя обойти вниманием и другой — мир реляционных баз данных. Я намеренно вставил прилагательное «реляционные» применительно ко всем основным СУБД, хотя ещё в 1970-х годах такое обобщение было бы неправомерным.

Тем не менее, именно реляционным СУБД удалось в 1980-х годах освободить программистов от знания ненужных деталей организации физического хранения данных, отгородившись от них структурами логического уровня и стандартизованным языком SQL для доступа к информации. Также оказалось, что большинство форматов данных, которыми оперируют программы, хорошо ложатся на модель двумерных таблиц и связей между ними. Эти два фактора предопределили успех реляционных СУБД, а в качестве поощрительной премии сообщество получило строгую математическую теорию в основании технологии.

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

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

Эта статья о том, как можно избавиться от дублирования сквозного кода, и как сделать его чуточку лучше с помощью АОП.

Приветствую, хабраюзер.
Уже была статья про чат-клиент на питоне на хабре. Данная статья и сподвигла написать свой велосипед в академических целях, но повторять чужой код не интересно, поставим задачу поинтереснее: Jabber(Асимитричное шифрование RSA)+PyQt.
Если интересно добро пожаловать под кат.

Написать расширение для google chrome несложно. Но при написании первого раширения могут возникнуть (и возникают) вопросы. Большинство мануалов по написанию первого расширения расчитаны на использования манифеста первой версии, поддержка которого в скором будущем прекратится.

В этой статье будет рассмотрено:

• Как составлять манифест v.2
• Как работать с удаленными ресурсами
• Как работать с cookies
• Как работать с local storage
• Как работать с уведомлениями

Так уж сложилось, что последние несколько лет я занимал самые разнообразные руководящие должности в полудюжине компаний, занимающихся разработкой программного обеспечения разного рода. Довелось побывать и тимлидом, и менеджером проекта, и группы проектов, руководителем отдела и руководителем технического направления; подопечных бывало от двух до ста пятидесяти человек, да и размеры компании варьировались от трёх до двухсот тысяч работников. Неизменным оставалось только одно: чисто управленческая работа, постепенный и окончательный отход от технических задач.

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

Для того чтобы превратить Марс в землеподобную планету, сначала придется избавиться от марсианской пыли. Первый этап очистки поверхности успешно реализован марсоходом MSL Curiosity.

Нидерландское правительство на прошлой неделе выпустило официальные рекомендации по «хактивизму» с целью поощрить белых хакеров раскрывать бреши в безопасности ответственно. Эти рекомендации устанавливают для этических хакеров формальную процедуру сообщения об ИТ-уязвимостях, пишет The Verge.

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

Компании Sony непросто дался вход на рынок смартфонов: наследие «бренда на двоих» — Sony Ericsson — повисло гирями и предыдущая линейка вышла невнятной.

Несмотря на то, что мы критиковали серию Xperia 2012 года (с которой еще не успели сбить круглый шильдик Sony Ericsson), очень здорово, что продажи у компании все же пошли, и во многом благодаря влагозащищенному смартфону V-серии. Его удачное позиционирование в качестве «первого пылевлагозащищенного Android-смартфона» и правильная цена сделали свое дело.

Теперь на CES 2013, японцы показали то, чего от них так давно ждали: свой первый по-настоящему сольный продукт, флагманский 5-дюймовый смартфон Xperia Z. Он получился бескомпромиссным и харизматичным, истинно «сонистайловым».

Я прочитал пост «13 причин не быть управленцем» и хочу написать ответ.

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

Таким образом, к примеру, есть мозг художника, и он не будет математиком. А математик часто не может писать гениальные стихи, и так далее. Бывают гении, типа Леонардо да Винчи, но это исключение.

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

Поэтому универсальных советов нет, каждому нужно искать свое дело.

Это было предисловие, а теперь про плюшки работы управленцем.

Итак, что в управлении проектами круто.

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

Ребята из команды github продолжают делать OpenSource простым и приятным занятием. С одним из последних обновлений они выкатили Contributions — дэшборд для профиля пользователя, в котором собрана вся информация о его активности.

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

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

Под катом можно найти любопытную подборку самых «зеленых» (в хорошем смысле) контрибьюторов на данный момент.

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

На первый взгляд это может показаться тривиальной задачей, не так ли? Если сторонами треугольника являются x и y, то, формально, формулой для вычисления гипотенузы будет:

sqrt(x*x + y*y)

Это работает теоретически, но на практике данный подход может приводить к ошибке. Если значение x достаточно велико, то вычисление x*x может привести к переполнению типа данных (ни один тип данных от этого не застрахован, если не рассматривать длинную арифметику), и результатом вычислений будет бесконечность.

С небольшой задержкой стал доступен для загрузки стабильный релиз Firefox. Официальный же релиз должен состояться сегодня, 8 января (скорее всего ближе к вечеру).
Что нового в этой версии:

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

Мой предыдущий пост "Как сделать 3D шутер на JavaScript за пару дней" показал, что тема разработки браузерных игр весьма интересна и по этому я решил очередные выходные посвятить еще одной моей задумке.

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

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

Когда вопрос заходит о хранении в БД гибких (заранее не известных, часто изменяемых) структур данных, разработчики обычно обращаются к «великому и ужасному» EAV-паттерну, либо к ныне модным NOSQL базам данных.
Не так давно такая задача стала и передо мной.
— EAV. Вызывает у меня стойкую неприязнь, да и сказано и написано об этом было очень много всего негативного (Кайт, Фаулер, Карвин, Горман). Главный минус в том, что при написании запросов приходится оперировать уже не реальными сущностями («Сотрудник», «Дом», «Клиент», то для чего и предназначен SQL), а объектами, орагнизованными на более низком уровне (извините за сумбур). Поэтому это был самый не желательный вариант.
— NOSQL. Поначалу очень заинтересовал этот вариант (в частности MongoDB). После продолжительного использования реляционок, первое время начинаешь испытывать чувство тотальной свободы, от которого захватывает дыхание. Хранение документов любой структуры, моментальное создание новых коллекций, запросы к ним — красота! Но после непродолжительного использования эйфория начала спадать, а проблемы обнаруживаться:
— Бедный язык запросов (ИМХО) + отсутствие джойнов;
— Отсутствие схем (хорошая статья недавно была на эту тему (и не только на эту) habrahabr.ru/post/164361);
— Отсутствие встроенной поддержки ссылочной целостности;
— Отсутствие прибамбасов в виде хранимых процедур/функций, триггеров, представлений и многого другого.
— В моем приложении помимо данных с гибкой(изменяемой) структурой также необходимо хранить обычные статические данные — таблица пользователей, посещений, сотрудников и т.д. Работать с которыми (опять же имхо) гораздо проще и (самое главное) надежнее в обычной реляционной базе (та же самая ссылочная целостность и пр.).

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

На случай, если вы пропустили предыдущие части — вот ссылки:
1 — Миникомпьютер из роутера с OpenWRT: разрабатываем USB-видеокарту
2 — Миникомпьютер из роутера с OpenWRT: пишем USB class-driver под Linux
Итак, приступаем к работе.