В своё время я уже видел такой конвертер здесь же на Хабре, написанный на питоне, но он на моей машинке сжирал много-много-много ресурсов и ни разу не смог моё избранное (а это 400+ постов) до конца сохранить, падая то на некорректном файле, то на «кривой» статье. Пришлось переписать, результаты трудов под катом.

Всем привет!

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

---

Java — это язык с мощными стандартными возможностями, но «Большая сила налагает большую ответственность». Я видел много java-кода, в котором чрезмерно (и зачастую — неправильно) использовались «редкие» свойства языка, в то время как основы основ были почти полностью проигнорированы. Эти наблюдения и послужили стимулом к написанию статьи.

Это не список обязательных к использованию каждым программистом особенностей языка. Скорее наоборот. Я разделил их на 3 группы: "для каждодневного использования", "для периодического использования" и "только для фреймворков и библиотек!". Правило простое: если вы понимаете, что используете указанные свойства чаще, чем рекомендуется, то, скорее всего, ваш код развивается по неправильному пути. Если же наоборот — вы редко используете какие-то свойства, чем я рекомендую, значит вы упускаете какие-то интересные и важные возможности языка.

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

Фильм «Смерть марсохода» в переводе от Airstrike напомнил мне, как в декабре прошлого года я насмотрелся/начитался про марсоходы и сделал свой «Спирит».

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

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

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

Мы продолжаем рубрику «задаем вопросы экспертам Intel». В предыдущем посте мы озвучили тему диалога — «интеллектуальная собственность в области ПО» и представили нашего эксперта — старшего инженера исследователя Intel, специалиста по вопросам интеллектуальной собственности, патентного и авторского права в области программного обеспечения Станислава Братанова. В комментариях и личных сообщениях было получено достаточное количество ваших вопросов, теперь время публиковать ответы на них. Вопросы, заданные публично, для удобства поиска снабжены ником автора.

«Покой — это ложь. Есть только страсть.
Через страсть я познаю силу.
Через силу я познаю могущество.
Через могущество я познаю победу.
Через победу мои оковы рвутся.
И Великая Сила освободит меня.»
— Кодекс ситов

Я хочу поговорить о темной стороне кода и о том, к чему это приводит. Что я понимаю под темной стороной кода? С моей точки зрения — это такой код, который был написан программистами, которые поддались желанию написать кое-как, исходя из своих собственных целей, а не целей продукта. Они оставили покой (размеренное написание кода согласно практикам) в угоду страсти (код ради кода). А если есть темная сторона, то есть и ее представители — Темные властелины, Дарты. Вот о них мы сегодня и поговорим.

На Хабре написано много статей об уязвимостях различных роутеров, о сканировании сетей wi-fi на Android-устройствах, о растущем их потенциале и т.д. В данной статье я хотел бы описать сервис/сервисы, которые позволяют полноценно или скорее удобно эксплуатировать уязвимости роутеров wi-fi с Android-устройства. Так или иначе, основным сервисом, о котором пойдет речь, является Routerpwn.

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

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

Я отвечу на вопросы: Что тестируем? Кто этим занимается? Зачем это все происходит? Что у нас есть?
А затем расскажу как все работает: опишу круги тестирования — с первого по девятый.

Что?

Наш продукт — корпоративное web-приложение Service Desk, написано на java.

Кто?

Я — лид группы автоматизированного тестирования; программисты код которых тестируем; ручные тестировщики, рутину которых мы искореняем; менеджеры верящие, что если тесты прошли, то все не так уж и плохо.

Зачем?

Цель моей группы — уберечь продукт от регрессионной спирали смерти.
Задача группы — необнаружение дефектов максимумом интересных способов с минимальным количеством ручного труда.

Что у нас уже есть?

900 коротких и не очень сценариев использования приложения закодированых в тесты.
CI Jenkins на шести серверах, три СУБД, два семейства ОС и три браузера под которые пишем продукт.

Как это работает?

Многие слышали про R — язык программирования и систему статистических вычислений. Язык весьма популярен за рубежом, а вот в России, к сожалению, на нём пишут относительно мало. Да и ресурсы на русском языке можно по пальцам пересчитать. Я считаю, что ситуацию нужно как-то исправлять.
На официальном сайте есть такая замечательная штука, как R reference card. В базовых пакетах R содержится множество очень полезных функций, которые делают программирование действительно быстрым и лаконичным. Но новички, как правило, большую часть самых прекрасных функций не знают. Да и не откуда узнать — мануалы очень большие, мало кто их полностью читает. А вот R reference card позволяет совершить быстрое путешествие по основной функциональности и вынести для себя много полезного.
Я решил перевести этот замечательный документ на русский язык. Но не просто перевести, а сделать его немного получше. Я чуток поменял структуризацию, для каждой функции поставил ссылку на документацию, убрал избыточные описания.
Предлагаю вам ознакомиться с результатом. Готов к любым замечаниям и предложениям, чтобы сделать этот список ещё лучше. Надеюсь, что данный обзор R окажется полезным для многих людей, которые решили начать писать на этом прекрасном языке.

Собственно задача весьма специфичная, но может еще кому-то эта работа пригодится. Вопрос целесообразности совместного использования Apache и Tomcat предлагаю оставить за рамками обсуждения. Задача была поставлена на работе уже как данность. Требуется обеспечить хранение сессий в Redis для PHP и Tomcat причем так, чтобы эти сессии были общими между ними. Продолжительное гугление результата не дало. И для PHP и для Tomcat существуют средства хранения сессий в Redis, но формат хранения у них разный. Все 3 найденные проекта для Tomcat сериализуют сессии в Redis с использованием бинарного формата для сериализации объектов Java. Также PHP и в Tomcat разные идентификаторы для Cookie сессии (PHPSESSID и JSESSID, соответственно).

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

По роду своей деятельности я нередко становлюсь свидетелем «священных войн» между коллегами-программистами на тему, какую же систему контроля версий выбрать для того или иного проекта. Роль системы контроля версий особо остро ощущается в случаях разработки и поддержки проектов с длинной историей. Вариантов инструментов много, но я хочу сконцентрироваться на двух, на мой взгляд, наиболее перспективных: Mercurial и Git. Далее попробуем рассмотреть возможности обеих систем с позиции их внутреннего устройства.

Этот топик будет отличаться от предыдущего топика Классический сапёр на html5 и LibCanvas. Его даже, скорее, можно назвать продолжением. И первая часть содержала пошаговую и детальную инструкцию, как заставить работать игрушку, то в этой части будет пару интересных приёмов, как её «оказуалить».

Играть в изометрический «Сапёр»

---

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

• Изометрическая проекция
• Оптимизация скорости отрисовки через грязный хак
• Спрайтовые анимации
• Draggable слои
• Оптимизация обработчика мыши согласно особенностей приложения

Язык PHP очень легок для изучения. Это, а так же обилие литературы «Освой _что_угодно_ за 24 часа» породило большое количество, мягко говоря, некачественного кода. Как следствие, рано или поздно любой программист, который выходит за рамки создания гостевой книги или сайта-визитки сталкивается с вопросом: «а если я здесь немножко добавлю, все остальное не ляжет?» Дать ответ на этот вопрос и на многие другие может юнит-тестирование.

В самом начале хочется оговориться — здесь речь не будет идти о TDD и методологиях разработки ПО. В данной статье я попробую показать начинающему PHP-разработчику основы использования модульного тестирования на базе фреймворка PHPUnit

Открыть новую закладку, скопировать в адресную строку

data:text/html, <html contenteditable>

и нажать Enter.

Вуаля.


При клике на белом поле появляется курсор, и можно писать мысли, заметки, наблюдения. Романы, стихи…

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

Формы состоят из самых разных элементов интерфейса. Если вы не знаете, как правильно с ними обращаться, вы можете сильно усложнить заполнение форм. Чаще всего ошибаются, применяя выпадающие списки (select menu).

Когда использовать

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

«И эти дурацкие иконки! Пиктограмма — это знак, который ни на одном человеческом языке невозможно объяснить. Не зря же появилась речь!»
Джеф Раскин.

Сегодня, какой бы продукт не проектировался, почти всегда уместно или нет — используются иконки. Заказчики требующие использования иконок в интерфейсе настолько свыклись с ментальностью повсеместного использования иконок, что это обстоятельство можно принимать за культурный феномен. Того же принципа придерживаются почти все разработчики.
Почему так получилось? Что в иконках не так? Можно ли без них обойтись?
Давайте попробуем разобраться.

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

Крис Парнин (Chris Parnin) из технологического института Джорджии решил восполнить этот недостаток и опубликовал чрезвычайно насыщенную статью со ссылками на различные исследования по этой теме.

Для начала, несколько фактов, которые относятся ко всем работникам интеллектуального труда. Задача, прерванная по ходу выполнения, занимает в два раза больше времени и содержит вдвое больше ошибок, чем та же задача, которая выполнялась без прерывания (Czerwinski:04). Офисные сотрудники вынуждены отвлекаться при выполнении 57% задач (Mark:05). Опросы говорят о том, что сотруднику требуется в среднем 15 минут, чтобы вернуться в нормальный ритм после того, как его отвлекли (vanSolingen:98).

Не очень строгий перевод материала mrbook.org/tutorials/make Мне в свое время очень не хватило подобной методички для понимания базовых вещей о make. Думаю, будет хоть кому-нибудь интересно. Хотя эта технология и отмирает, но все равно используется в очень многих проектах. Кармы на хаб «Переводы» не хватило, как только появится возможность — добавлю и туда. Добавил в Переводы. Если есть ошибки в оформлении, то прошу указать на них. Буду исправлять.

Статья будет интересная прежде всего изучающим программирование на C/C++ в UNIX-подобных системах от самых корней, без использования IDE.

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