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

Мне нравится записывать полезные вещи об интерфейсах, свойствах, методах, функциях, типах данных, и обо всём прочем, что относится к веб-разработке. Так я заполняю пробелы в знаниях. Сейчас я занят документацией к Node.js, а до этого проработал материалы по HTML, DOM, по Web API, CSS, SVG и EcmaScript.

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

В недавней статье на Хабре уже шла речь о том, как закупаться на Google Play в разделе Devices прямо из нашего захолустья. Тема бесспорно интересная: Nexus 7 пока в России и близлежащих странах вообще не водится, а Galaxy Nexus, скорее всего, просто обойдется вам значительно дороже, если, конечно, вы не живете в Москве или Питере. Проблема только в том, что рецепт оказался несколько нестабильный: лично меня Самая Добрая Корпорация небезосновательно заподозрила в подтасовке личных данных, а судя по комментариям – я такой оказался далеко не один.

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

Под катом новый рецепт и совсем чуть-чуть скриншотов.

Привет, %username%. Предлагаю отвлечься от решения проблем и немного расслабиться после первого трудового дня на этой неделе. Дело в том что у меня есть замечательная девушка (ага, хвастаюсь), пишущая неплохие рассказы. Но пишет она их в основном для себя, «в стол», т.к. ни блога не имеет, ни ЖЖ и вообще нигде не публикуется. И вот сегодня скинула мне рассказ настолько мне понравившийся, что я даже выпросил разрешение опубликовать его здесь. Тема не нова, но написано по-моему очень даже неплохо, думаю сообществу понравится. Итак, впечатления от года жизни с программистом.

Жизнь с программистом

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

Решил реализовать на разрабатываемом портале авторизацию (регистрацию) и идентификацию пользователей с помощью инструмента разработчика социальных сетей (Social Networks REST API) – тематика далеко не новаторская, активно используется и очень удобная в использовании. Как бы перечислять все удобства и преимущества использования на своих сайтах подобного функционала не буду, но замечу, что меня очень устраивает не запоминать пароли для каждого сайта (пусть даже если у меня пара-тройка стандартно используемых), не участвовать в утомительных регистрациях с пересылками писем и подтверждениями, а также лишний раз не сталкиваться с каптчами.

Как можно превратить слово в картинку? Об этом повествует книга «Word as Image» от Ji Lee, бывшего креативного директора Google Creative Labs. В книге представлено более 100 способов такого превращения. Книгу можно приобрести на Amazon, как источник вдохновения. Я думаю, must have для художников логотипов, о чем повествует промо-ролик (почему-то не встраивается в топик).

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

На прошлой неделе я проводил несколько интервью, чтобы нанять Senoir Java developers с опытом около пяти лет. После них я почувствовал, что фреймворки делают жизнь разработчиков проще, но в тоже время делают их тупее. Каждый указывает практически все новые фреймворки в своем резюме в виде «Мощный опыт работы с Spring, Hibernate, Web Services и так далее».

Вот как проходили собеседования.

Я: Вы использовали Spring в своем последнем проекте. Какие преимущества использования Spring?
Претендент: Мы можем настраивать beans в XML, а Spring возьмет на себя создание экземпляра и отдаст его нам.
Я: Если Spring только для создания объектов, зачем он вообще нужен – я могу напрямую создать экземпляр, используя «new». Почему мне стоит настраивать имена классов в XML и получать объект из Spring?

По просьбам трудящихся пишу статью про Spring IoC. Я не настолько гуру в этом вопросе, впрочем могу кое-что поведать.

Часто когда начинаешь работать на SWING сталкиваешься с проблемой понимания Layout.
Сама идея очень хорошая, но для людей которые работали только в визуальных средах это становится большой проблемой. Не может человек понять почему быстрее написать код чем накидать его в GUI дизайнере. Сам я со свингом плотно работаю около 2 лет и вот решил рассказать про замечательную библиотеку JGoodies Form Layout. Статей наверное пока будет только три, если все хорошо буду писать дальше.

И так часть первая вводная.

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

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

Я, будучи недавно в такой же ситуации, гуглила, искала мануалов на Хабре (кое-что нашла: Десять советов начинающим программистам, Начинающему программисту про стартапы и не только…), но в итоге всё же была вынуждена обратиться за советом к одному хорошему человеку, который составил для меня вот такой план. С разрешения этого человека размещаю данный план на Хабре – вдруг он пригодится и кому-то ещё. (Тем более, что перечисленные книги относятся к «золотому фонду» литературы в данной сфере и проверены временем.)

UPD: Новичкам советую обратить внимание на комментарии — там активно и аргументированно корректируется этот план.

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

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

По сравнению с традиционными, механизм создания и хранения неграфической информации в MultiCAD.NET API гораздо компактней и удобней в использовании. Кроме того, он универсален и может быть одинаково применен для различных типов данных в чертеже: графических элементов, листов или самого чертежа. В качестве дополнительной информации могут использоваться данные различных типов.

Как это работает и как применяется на практике смотрите под катом.

Play! и Lift, — эти два фреймворка являются олицетворением того, куда движется основной поток Scala веб-разработчиков. Воистину, попробуйте поискать на Stack Overflow фреймворки для Scala и вы поймете что я прав. Я верю, что процент здравомыслящих людей, которым надоели сложные комбайны, велик, поэтому расскажу про «другой» фреймворк Xitrum.

Вы когда-нибудь интересовались механизмом работы ssh-ключей? Или тем, насколько безопасно они хранятся?

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

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

Итак, если вам доводилось прибегать к аутентификации по ключу, то у вас, скорее всего, есть файл ~/.ssh/id_rsa или ~/.ssh/id_dsa в домашнем каталоге. Это закрытый (он же приватный) RSA/DSA ключ, а ~/.ssh/id_rsa.pub или ~/.ssh/id_dsa.pub — открытый (он же публичный) ключ. На сервере, на котором вы хотите залогиниться, должна быть копия открытого ключа в ~/.ssh/authorized_keys. Когда вы пытаетесь залогиниться, ssh-клиент подтвержает, что у вас есть закрытый ключ, используя цифровую подпись; сервер проверяет, что подпись действительна и в ~/.ssh/authorized_keys есть открытый ключ, и вы получаете доступ.

Что же хранится внутри закрытого ключа?

Команда проекта GeeksLab 18 января 2014 года в Одессе провела конференцию Happу New Front-End: О фронтенде по-новому!. В рамках конференции были подняты темы современной верстки, разработки фронтенда на чистом JavaScript, а также использования различных CSS и JavaScrpt фреймворков для построения фронтенда веб-проектов. С докладами выступили представители таких компаний как: rollApp, Universal Mind, DataArt, Ciklum, Elis, R2Crew, RootUA Media, WMSoftware, Electric Cloud. Презентации и видеозаписи докладов под катом.

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

Постараюсь очень лаконично и быстро обрисовать ситуацию с хэшами.

Сразу определю какую задачу применения хешей буду рассматривать — аутентификация пользователей. Не токены восстановления паролей, не аутентификация запросов, не что-то еще. Это также не статья про защиту канала передачи данных, так что комментарии по challenge-response и SSL неуместны!

Какое-то время назад пролетала статистика от одного из преподавателей Coursera Марка Морли [1], что «около 3% записавшихся студентов доходят до стадии финального экзамена и лишь 1,5% сдают его».

Статистика наших онлайн программ чуть выше: у нас до конца всех занятий доходят около 20% слушателей. Мы, правда не делаем экзаменов, потому что искренне верим, что в теме управления людьми и коммуникаций формальные экзамены чуть более чем бесполезны. Но 20% точно прослушивают все занятия до конца (статистика собрана на 1500+ слушателях за 3 года). Ну так у нас и слушателей поменьше чем у Coursera, есть возможность практически личного воздействия на людей. :)

Однако, что та, что та статистика — не утешительна. Или нормально все? На эту тему мой коллега Слава Панкратов недавно написал отличный текст про то, как мы учимся по книгам (к курсам тоже применимо), которым текстом и хотелось бы поделиться.

Слава Панкратов «Синдром Алисы в зазеркалье: что и как читать?..»

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

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+)
• технологию агрегации интерфейсов и перераспределения нагрузки между ними
• некоторые вопросы стабильности и безопасности
• как изменить схему существующей сети, чтобы всем было хорошо

Суть проблемы

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

Иными словами, если свитч недавно получил пакет от компьютера А в порт 1, то в таблицу заносится соответствие «комп. А» -> «порт 1», и дальнейшие пакеты, адресованные компьютеру А, автоматически пересылаются только в порт 1, и никуда больше, что экономит пропускную способность сети и делает неэффективными пассивные перехватчики траффика.

Но что делать свитчу, если приходит широковещательный пакет (broadcast)?
Логично предположить, что такие пакеты пересылаются во все порты, кроме того, откуда изначально были получены.
Что, при определённой конфигурации сети, может привести к весьма печальным последствиям…

Источник: King's Bounty

Привет, Хабр!

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

Начнем с загадочного понятия «карьерный трек».

Представим себе ситуацию, когда есть написанные тесты на JUnit`е и все работает отлично (ну хотя бы тесты написаны).
Но появляется чудо-идея, что TestNG был бы для этих тестов удобнее. Не будем вдаваться в холивар, какой из фреймворков лучше, круче или удобнее. Но факт в том, что API у них разный.

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