Однажды у меня появилась навязчивая идея: посмотреть, а что же там такого покерный клиент отправляет на сервер. Как Вы понимаете, крупные покерные румы используют SSL для передачи данных. Протоколы, основанные на асимметричном шифровании, подвержены только одному известному мне виду атак — MitM (Man in the middle — человек посередине).

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

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



Я уже не помню как и когда в моей голове поселилась эта странная идея — собрать ламповый усилитель. Зачем тоже не совсем понятно — меломаном я не являюсь, домашними кинотеатрами давно и быстро переболел, на память об этом времени остались напольные колонки Wharfedale Diamond 8.4, последние годы использовавшиеся исключительно как декоративная подставка для цветов. Как бы то ни было, мысль настолько глубоко поселилась в моей голове, что началось неспешное изучение профильных ресурсов, чтение форумов, поиск схем ламповых усилителей «для чайников» и т.д. и т.п. Отсутствие какого-либо опыта общения с ламповой техникой (самый современный гаджет, который я помню — это ч/б телевизор в студенческой общаге в начале 90-х годов прошлого века) отпугивало и привлекало одновременно.

Знакомьтесь, это обычный «литровый» пакет молока:

• Проверка на внимательность: там 900 грамм. Рядом несколько по 950. Но пакет может быть воспринят как литровый.
• Проверка на знание физики. Рядом лежит похожий кефир. Объём измеряется в миллилитрах, масса — в граммах. Плотность кефира трагически выше плотности воды. То есть 900 грамм кефира 3,2% жирности — это примерно 874,5 миллилитров.

Второй пациент:



25 лет гарантии. Круто, правда? Есть одна проблема. Надо сохранять чек. Проверка, опять же, на знание физики. Чек у них печатается на обычной кассовой термоленте (я проверил на месте). У меня в офисе лежит много чеков. Мы их ксерокопируем, потому что через год-два они полностью выцветают. Самый старый чек, который видел коллега, держался 3 года в папке в архиве. UPD: смотрите самый низ топика, Икея ответила.

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

Осторожно, трафик: под катом много находок с фотографиями.

Введение

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

Пост содержит фотографии, видео и схемы.

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

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

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

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

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

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

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

Доброго времени суток.

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

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

Британский программист и писатель Джон Грэм-Камминг (John Graham-Cumming) открыл познавательный блог Movie Code, посвящённый использованию компьютерного кода в голливудских фильмах. На сайте собирают кадры из фильмов и объясняют, откуда взят код и что конкретно он делает в реальности. Не секрет, что режиссёры часто подбирают код совершенно произвольным образом, иногда получается очень смешно.

Например, вверху показан кадр из боевика «Штурм Белого дома», где режиссёры использовали код нескольких open source программ, которые написаны в 2007-2008 годах для демонстрации Raw Sockets с целью инъекции пакетов. Свой код в официальном трейлере опознал специалист по информационной безопасности с сайта SecurityTube.net.

Основано на реальных событиях: «Mini-Desktop своими руками»

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

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

На конференции NDC 2013, недавно прошедшей в Лондоне, Мадс Торгерсен (Mads Torgersen), являющийся одним из разработчиков спецификации языка C#, рассказал в своём докладе “The Future of C#” о возможных нововведениях в нём.

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

Если вы гуляли по любым людным улицам, уверен, вы поймете, о чем я. За последние 3-4 года значительно возросло число людей, уткнувшихся в свои смартфоны во время прогулок и совершенно отстраненных от окружающего мира. Если человеку нужно убить время (или он страдает прокрастинацией), он погружается в пролистывание бесконечных фидов фейсбука, твиттера или тумблера. Черт, я видел, как люди делали это во время просмотра ТВ-шоу, которого они ждали целую неделю.

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

Лучший учебник по физике всех времен и народов теперь доступен онлайн.

Плох тот конструктор бумажных самолётиков, который не пытался добиться от своего аппарата как можно более длительного и предсказуемого полёта. Разные сорта бумаги, конструкции и бесконечные нюансы сборки, подгибы закрылков и рулей… Американец Шай Гойтейн, пилот с 25-летним стажем, уже полтора года работает на стыке детских увлечений и современных технологий. Результат его стараний — набор для превращения любого бумажного самолёта в радиоуправляемый электролёт, способный продержаться в воздухе до десяти минут — собрал необходимую сумму на Кикстартере всего за несколько часов. Пожалуй, кроме красивой идеи и элегантной реализации, в успехе кампании большую роль сыграл талантливо сделанный промо-ролик, на мой взгляд, один из самых удачных на Кикстартере:

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

Ущербный — имеющий изъян, неполноценный. Вредный, недостаточный.

Наследование

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

Не так давно вышел mvc 5 и одним из ключевых изменений является система авторизации. При создании «пустого» mvc 5 проекта есть возможность подключить авторизацию для Facebook, Google, Twitter и Microsoft аккаунтов. Я тут же полез разбираться с тем как это все работает и результатом стал «middleware» модуль для сети Вконтакте. Его можно поставить через nuget пакеты поискав «Duke.Owin.VkontakteMiddleware» и посмотреть исходники: github.com/DukeNuken/Duke.Owin.VkontakteMiddleware

В интернете есть много статей о owin авторизации и проекте katana с которыми можно ознакомится и даже скачать исходники.

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

Итак, поговорим о:

• InternalsVisibleToAttribute
• TypeForwardedToAttribute
• CallerMemberNameAttribute
• MethodImplAttribute

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

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

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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