При работе над одним проектом возникла необходимость написать некое подобие тестовой системы. Задача формулировалась примерно так:

• из N записей в базе необходимо выбрать m (3-5) случайных строк в серии из k выборок (преимущественно k=2).

А теперь то же самое человеческим языком: из таблицы нужно два раза выбрать по 3-5 случайных записей. При этом не должно быть дубликатов и выборка должна происходить случайным образом.

Первое, что приходит в голову:

 SELECT *
  FROM data_set
  WHERE id NOT IN (1,2,3,4, 5)
  ORDER BY random()
  LIMIT 5;

И это даже будет работать. Вот только цена такого решения…

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

Если вы сами проводили конкурсы и всё было ок — не читайте топик. Если где-то ждал облом — добро пожаловать под кат.

Примечание переводчика: Перевод первой статьи из блога «A Year of Productivity» был благосклонно встречен хабра-сообществом, и меня попросили перевести еще несколько статей из этого блога. Приведенная ниже статья — самая большая и самая близкая к практике, её перевод затянулся у меня на несколько месяцев. Как и прошлый раз рекомендую читать комфортными порциями, записывая (или копируя куда-нибудь) советы, которые хочется попробовать применить на практике.

«Хаки» времени

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

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

Для начала вот несколько моих любимых приемов по тому как:
-  получить больше времени;
-  тратить время на правильные вещи.

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

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

Имеется сервер с установленным Apache. Установка и настройка производится удобно и модно puppet-классом apache. Для простоты все будем хранить в основном манифесте site.pp. Все появляющиеся проблемы в ходе развития примера актуальны и в случае разнесения кусков логики по модулям.

Не сомневаюсь, что большая часть читающих этот пост родилась еще в пленочную эру, и прекрасно помнит, зачем нужно зажигать особую красную лампу, и чем фиксаж отличается проявителя. У себя в ванных мы превращали отщелканную пленку в настоящие фотографии, а многие этим балуются и до сих пор. Но, цифровая фотография сегодня вне конкуренции, на самом деле, она существует с 1975 года. А первая цифрозеркалка появились уже в 1991 году. Kodak DCS 100 была модифицированной пленочной Nikon F3 с внешним жестким диском. По началу, это были дорогие и громоздкие решения. К тому же, вплоть до появления Nikon D1 и Canon EOS 1D в 2001 году, качество снимков, получаемых с пленки, радикально превосходило цифру.


Процесс проявки

Что будущее именно за цифровым фото стало окончательно понятно в 2003 году. И успех первой недорогой зеркалки Canon 300D, с ценником менее 1000$, тому подтверждение. Вплоть до 2008 года зеркалки практически безраздельно царствовали на рынке, однако серьезные камеры со сменной оптикой, но без зеркала, отстали от появления 300D всего на один год.

Комментарии к первой части продемонстрировали еще одно популярное заблуждение, с которого я хотел бы начать вторую часть статьи. Многие люди несправедливо упрекают патентную систему в торможении прогресса, так как считают патенты удостоверением собственности на изобретение, в то время как патент лишь регистрирует преимущество владельца при коммерческом использовании изобретения. Разница в определениях огромна. Во-первых, преимущество держателя патента ограничено по времени. Во-вторых, и заявка на изобретение, и сам патент являются открытыми, публичными документами. Фактически говоря, изобретение становится достоянием человечества. Разумеется, в базе патентов — копилке знаний — найдется много мусора, тривиальных, никому не нужных или даже глупых изобретений, однако ценность копилки, как и любого механизма свободного обмена информацией вообще, невозможно переоценить. Патенты не мешают изобретать! Как раз наоборот: полная гарантированная доступность предыдущих изобретений способствует прогрессу, помогает не изобретать в очередной раз велосипед, а совершенствовать действительно нужные и перспективные направления. Патентная система была призвана создать аналог академической традиции публикации работ, и надо признать, достаточно успешно справляется с этой задачей. Закон обязывает соискателя “предоставить исчерпывающее описание и детали изобретения в таком виде, что человек с ординарными способностями будет в состоянии его воспроизвести”. Добавьте к этому регламентированную форму подачи, какую-никакую проверку и фильтрацию патентных экспертов, современную компьютеризированную систему поиска и каталогизацию, и мы получаем практически идеальную для изобретателя картину: изучай на здоровье, пользуйся, улучшай, твори свое!

В последнее время мировую IT-прессу буквально захлестнули патентные «новости». Чуть ли не каждый день мы читаем о компании А., запатентовавшей что-то-там, и о компании Б., подавшей в суд на компанию В. Я не знаю причин по которым в общем-то узкоспециализированная и достаточно нудная тема стала интересна широкому кругу читателей, но вижу насколько ошибочны представления очень многих людей, судя по разворачивающимся вокруг патентных новостей дискуссиям. В данной статье я хотел бы рассказать о некоторых часто встречающихся заблуждениях, причем рассказать популярным языком, не скатываясь с одной стороны в юридические дебри, а с другой — в желтизну вроде «Эппл — патентный тролль».

Самое часто встречаемое заблуждение — рассмотрение патента в качестве наступательного оружия. Вася запатентовал колесо? Значит Вася начнет днем и ночью искать всех остальных производителей колес и вставлять им палки в продукцию. Это не так. За исключением единичных адвокатских контор (настоящих патентных троллей!), IT-компании никогда не оформляют патенты для наступления/наезда на других, это попросту не вписывается в бизнес-процесс. Главных причин написания патентов всего три: паритет, давление и привлекательность для инвесторов.

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

Главным героем сегодняшнего обзора стал девайс, который использует все 4 отверстия моего монитора с максимальной, на мой взгляд, пользой. О каких отверстиях я говорю? )



Нет…топ? Неа )

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

У каждого есть одна-две любимые книги, которые могут понравится другим, поделитесь пожалуйста, заразите. Думаю многим будет интересно поставить в очередь «к прочтению» несколько новых. Давайте устроим «дегустацию» книг в формате: одна книга — один комментарий. Чтобы другие могли добавить в избранное (и оценить, и обсудить) каждую книгу по отдельности.

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

Пара слов о себе: 1.5 года работаю java-программистом в городе Лимассоле (который расположен в греческой части острова), живу там же с семьей.

Данной статьей я постараюсь продолжить обзор стран, начатый в Денег нет, погода дрянь и правительство ввело новые поборы. Что делать?. Я не хочу обсуждать почему, зачем, что меня двигало к переезду (кому-то весело и комфортно только в Нью-Йорке/Лондоне, а кто-то весьма доволен и в деревне), а постараюсь просто привести некоторую информацию. Здесь на сайте довольно много людей из Австралии, надеюсь где-то меня поправят, что-то добавят. С удовольствием отвечу на все вопросы в комментариях.

Захотелось мне как-то попробовать сжать ресурсы dfm форм своего приложения, плюсы довольно спорные (сложные формы могут содержать много графических ресурсов которые в dfm файле хранятся как буфер с bmp, который можно неплохо сжать, так же защита от просмотра и редактирования ресурсов форм), но ведь есть несколько программ позволяющих такое делать, значит кому-то нужно.

Напишем приложение DFMCompressor, которое будет извлекать dfm ресурсы из exe файла, сжимать их и записывать обратно заменяя оригиналы.

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

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

У нас на каждой физической игре есть отладочные коды, «зашитые» в разные компоненты. Я помню, что обещал топик про дебаг нашего производства в реальном мире. Вот он. Заодно может пригодиться интернет-магазинам.

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

В одной из дискуссий недавно, я перечислил основные системы, делающие работу ИТ-компании цивилизованной. Список получился весьма обширный, и я решил оформить его как самостоятельную статью.

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

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

Краткий спойлер содержимого: VCS, репозиторий исходного кода, code-review, build-сервера, CI, таск-трекер, вики, корпоративный блог, функциональное тестирование, репозиторий для пакетов, система управления конфигурацией, бэкапы, почта/jabber.

Картинка с фрагментом обсуждаемой инфраструктуры:

Эта заметка навеяна мелькавшими последнее время на хабре постами двух тематик — «интересные команды unix» и «как я подбирал программиста». И описываемые там команды, конечно, местами интересные, но редко практически полезные, а выясняется, что реально полезным инструментарием мы пользоваться и не умеем.
Небольшое лирическое отступление:
Года три назад меня попросили провести собеседование с претендентами на должность unix-сисадмина. На двух крупнейших на тот момент фриланс-биржах на вакансию откликнулись восемь претендентов, двое из которых входили в ТОП-5 рейтинга этих бирж. Я никогда не требую от админов знания наизусть конфигов и считаю, что нужный софт всегда освоится, если есть желание читать, логика в действиях и умение правильно пользоваться инструментарием системы. Посему для начала претендентам были даны две задачки, примерно такого плана:
— поместить задание в крон, которое будет выполняться в каждый чётный час и в 3 часа;
— распечатать из файла /var/run/dmesg.boot информацию о процессоре.

К моему удивлению никто из претендентов с обоими вопросами не справился. Двое, в принципе, не знали о существовании grep.



Поэтому… Лето… Пятница… Перед шашлыками немного поговорим о grep.

Одним из методов сбора информации о процессе является проведение интервью с владельцем или участниками этого бизнес-процесса. Такой традиционный подход встречается очень часто, особенно у начинающих бизнес-аналитиков и матерых консультантов из Big4. Казалось бы очень разумно выслушать человека, формализовать его монолог и согласовать результат с ним же — это быстро и не затратно. Одно плохо — на этапе анализа адекватности результата моделирования деятельности (если такое предусмотрено) происходит отбраковка собранных данных по причине их несогласованности и противоречивости, процедуру сбора данных о ходе процесса надо повторять сначала, «на радость» всем участникам проекта. Почему такое происходит? Как видно из заголовка, дело в респондентах. Ниже на конкретных примерах из личного опыта я покажу, почему был сделан такой вывод и как с этим бороться.