3D кинотеатры за последнее время расплодились в больших количествах. Не сильно в последнее время от них отстают в распространённости и 3d-телевизоры. Однако, что именно стоит за маркетинговым “3D” в каждом случае не всегда ясно и очевидно.
Стоит отметить, что правильнее было бы назвать это “стерео”-кино, но термин “стерео” уже давно и прочно (просто, видимо, по праву первенства) закрепился за звуком (в этом плане показательно, например, название журнала “Стерео и видео”). Поэтому маркетологам пришлось использовать термин “3D”, который ассоциируется с объёмным изображением в том или ином смысле. В данном случае понимается восприятие мозгом объёма за счёт подачи каждому из глаз изображения, чуть отличающегося от изображения для другого глаза, аналогично тому, как отличаются получаемые глазами изображения в жизни.

В данной статье я опишу способ скрытия приложений на компьютере, удобного запуска и быстрого скрытого их завершения на примере игры Warcraft III в Windows XP.

Так сложилось, что, проходя службу в нашей доблестной армии, у меня периодически появлялся доступ к компьютеру. И так сложилось, что, уходя в армию, я забыл выложить свою флешку, которую постоянно ношу с собой в кошельке. На этой флешке было много разного барахла, один миллион папок с названием «учеба» и архив с названием… tada! wc3.rar
Радости моей не было предела, но тут появился вопрос — как проводить вечера за любимой игрой и при этом остаться незамеченным? На все про все, у меня было 2-3 секунды на закрытие игры.

Ученые из лаборатории iBionicS из Университета Северной Каролины продемонстрировали свою разработку — радиоуправляемого таракана.

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



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



Теперь дело за малым — поместить еще и камеру — и шпионское устройство с невероятной проходимостью готово!

Признавайтесь, кто в детстве часами напролёт просиживал за игрой в «Денди» или «Сегу»? А кто по мере прохождения игры записывал пароли на бумажку или в специально заведённую тетрадку? Если это вы, и раз уж вы читаете этот сайт, то у вас наверняка хоть раз возникал вопрос: «а как же это работает?»

Я постараюсь объяснить принципы работы классических механизмов генерации паролей на примерах из игр моего детства. Заранее прошу меня извинить за то, что все примеры будут с платформы NES (да, та, которая «Денди»), хотя тематика только ею не ограничивается. Так уж получилось, что не нашёл в себе достаточно мотивации, чтобы провести немного больше исследований и написать немного больше текста.

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

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

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

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

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

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

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

Окончив институт и устроившись на работу, я осознал, что совершенно не создан для офисной или выездной работы, четких распорядков, начальников и прочей рутины. А ходить на работу каждый день было ну совсем невыносимо. Хватило меня на пол года :) Потому, несмотря на не пыльную работу, весьма высокую зарплату, а по меркам вчерашнего студента, так вообще шикарную, я дождался первого же срача с начальством и красиво хлопнул дверью. С тех пор развлекаю себя сам и доволен жизнью. О нюансах вольной жизни бывшего фрилансера электронщика я и хочу поведать в этом посте.
Все нижеследующее это исключительно мой практический опыт и я не уверен, что у вас все получится именно так.

Бабло
Начну с самого интересного, с денег. Скажем так, под конец моей деятельности (примерно 2010), не особо напрягаясь, работая около двух-трех дней в неделю, можно было смело делать тысяч по 50-70 рублей. Это в Челябинске. Если работать каждый день, то легко было делать от 150 тысяч рублей в месяц и более, но я для этого был слишком ленив. А теперь по порядку.

Я когда-то работал в компании, где нельзя было говорить о своей зарплате под страхом… я даже не знаю чего. Как дети испытывают ужас от того, что “взрослые заругают”, так и мы боялись ей делиться. О том, какая кара нас ожидает, приходилось только догадываться.

Ад в представлении Босха.

И все равно все все знали. Почему? Потому что чтобы закон работал, за ним должна стоять идея, которую разделяет большинство. Какая идея стояла за этим законом? Идея скрыть несправедливую оплату труда. Ведь если она справедливая, то зачем скрывать?

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

Но прежде чем вступать на путь взращивания из себя старшего разработчика, нужно задать себе простой вопрос: «А мне нравится программировать?».


Старший разработчик. Взято отсюда.

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

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

Valve Software продолжает нанимать известных специалистов Linux, что вполне логично, если учесть озвученные намерения компании выйти на новую ОС и слухи о создании консоли Valve Box. Совсем недавно к Valve присоединились ведущие разработчики движка DarkPlaces (кроссплатформенные шутеры от первого лица Xonotic и Nexuiz) и создатель кроссплатформенной игры Battle for Wesnoth.

Новое приобретение корпорации — Сэм Лантинга, работавший ранее в Loki Software, где до банкротства компании он портировал некоторые Windows-игры на Linux, например, Rune, Tribes 2, Railroad Tycoon II и многие другие хиты конца 90-х. Его опыт в работе с Linux составляет более 10 лет, именно Сэм создал и продолжает разрабатывать популярную кроссплатформенную библиотеку Simple DirectMedia Layer, используемую при написании мультимедийных программ (в основном игр) не только на Linux и Mac OS X, но и Windows.

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

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

Ниже показан результат обработки реального размытого изображения (не с синтетическим размытием). Исходное изображение было получено камерой Canon 500D с объективом EF 85mm/1.8. Фокусировка была выставлена вручную, чтобы получить размытие. Как видно, текст совершенно не читается, лишь угадывается диалоговое окно Windows 7.



И вот результат обработки:



Практически весь текст читается достаточно хорошо, хотя и появились некоторые характерные искажения.

Под катом подробное описание проблем деконволюции, способов их решения, а также множество примеров и сравнений. Осторожно, много картинок!

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

Привет, уважаемый хабраюзер!

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

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

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

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

Простота — дух эффективности. // A. Freeman

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

Локализация здесь осуществляется довольно нехитро. Все строки, требующие перевода, оборачиваются в макрос _TR():

wprintf(L"%s\n", _TR("Some translating string"));

Макрос возвращает нужную версию текста в зависимости от текущего используемого языка. Определён он следующим образом:

#define _TR(x) g_Translator.Translate(x)

Здесь происходит обращение к глобальному объекту g_Translator, который в функции Translate() считает в рантайме crc32 от указанной строки, ищет в своей xml-базе перевод с совпадающей контрольной суммой и возвращает его.

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

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

Преамбула:
Имеем в наличии TortoiseSVN и Total Commander, и активно их используем в работе.
Практически все действия в Total Commander'e успешно совершаются одной только клавиатурой, без использования мышки, какими-либо горячими клавишами. Главное их найти/знать/привыкнуть, и работа становится в разы проще и быстрее.
TortoiseSVN же из коробки предоставляет нам только пункты в контекстном меню, до которого можно добраться двумя способами:

• Мышкой. При активной работе, тянуться каждый раз до мышки, реально начинает напрягать уже через пару дней/часов/минут работы (зависит от крепости нервов разработчика) и времени занимает это довольно много.
• Через клавишу контекстного меню + стрелок. Этот вариант конечно чем-то проще и быстрее (ибо не надо тянуться за мышкой), но всё так же не удобен и всё такой же медленный.

Хочется все действия с TortoiseSVN выполнять так же быстро, как и действия в самом Total Commander'e.
Т.е. через горячие клавиши, в одно нажатие.

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

I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial propertyеу
Is loop-free connectivity.
A tree that must be sure to span
So packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least-cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
Then bridges find a spanning tree.
— Radia Joy Perlman

Все выпуски

6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование

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

Итак, сегодня обсуждаем:

• проблему широковещательного шторма
• работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+)
• технологию агрегации интерфейсов и перераспределения нагрузки между ними
• некоторые вопросы стабильности и безопасности
• как изменить схему существующей сети, чтобы всем было хорошо

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

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

Заинтересовавшихся прошу под кат.