От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

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

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

По мотивам «Коанов Вима».

Тишина
Что-то одно, но хорошо
Только богам
Хобгоблин
Длинное и короткое

Тишина

Python-программистка передала свой файл ~/.gitconfig мастеру Гиту. Среди строчек кода было следующее:

[alias]
; Явное лучше подразумеваемового. Если мы хотим выполнить слияние,
; нам следует сделать это самим.
pull = pull --ff-only

Мастер Гит кивнул. «git pull origin master», — сказала программистка.

Автор статьи — Татьяна Курносова, но она поехала покорять горы Киргизии. Поэтому честь опубликовать этот пост выпала мне.

В компании 2ГИС помимо известных Desktop, Mobile и Online-приложений, разрабатывается множество внутренних Enterprise-продуктов. Эти продукты скрыты от глаз пользователей, однако, именно с их помощью выполняется колоссальная работа по обеспечению всей инфраструктуры 2ГИС картографическими и справочными данными. Обработка этих данных трудозатратна и требует безошибочных расчётов, поэтому перед «приёмом на работу» все продукты тщательно тестируются.

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

В прошлом году в нашей компании появился не только Web, но и Windows клиент. Так как средства автоматизации тестирования, которыми мы пользовались для Web (например Selenium) в данной ситуации мы конечно использовать не могли, перед нами возникла необходимость поиска технологии автоматизированного функционального тестирования для Windows приложений.

Критерии нашего поиска были следующими:

• Среда разработки функциональных тестов должна поддерживать как автоматическую запись тест-кейсов (для использования тестерами с минимальным опытом программирования), так и возможность писать отдельные части тестов вручную
• Так как клиент разрабатывается на C#, хотелось бы и функциональные тесты писать либо на C#, либо на одном из .NET языков
• Должна быть поддержка Data-Driven Testing
• Для идентификации элементов пользовательского интерфейса желательно должен использоваться XPath
• Код и все артефакты тестирования должны храниться в той же системе контроля версий, в которой хранится наш основной код (в нашем случае — Git)
• Данная технология автоматизированного функционального тестирования должна быть легко встроена в нашу систему непрерывной интеграции (Jenkins)

От редактора. Тема книг, вернее, тема знаний, которые в них содержатся, всегда была близкой для ABBYY. Мы многожды участвовали в проектах по оцифровке книжных собраний – и европейских, и отечественных. Поэтому, когда ваш редактор наткнулся на весьма неожиданную англоязычную статью на тему сохранения библиотечных книг, у него сразу возникло желание перевести её на русский и обсудить с вами, читателями. Автор материала — библиотекарь в школе.

Не могу поверить, что вы выбрасываете книги!

Я библиотекарь, но уже не библиофил.

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

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

Изучив предложенные в статьях «Правильный Singleton в Java» и «Реализация Singleton в JAVA» варианты решений и «пораскинув мозгами», я предположил, что смогу представить еще два похожих друг на друга варианта создания Singleton'а, практически лишенных многих недостатков тех решений, которые были изложены ранее в упомянутых статьях. Но хочу начать с постановки задач, решение которых определит, добились ли мы желаемого результата.

Требования:
1. Потокобезопасность
2. Сериализуемость изменений ссылки на объект-Singleton
3. Управляемость создания объекта в блоке try-catch
4. Создание объекта-Singleton вне конструктора
5. Несериализуемое получение ссылки на объект-Singleton, обеспечивающее лучшую производительность.
6. «Ленивая» инициализация объекта-Singleton

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

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

В этой статье я хочу затронуть тему одного из наиболее распространенных паттернов объектно-ориентированного программирования – Singleton. Но в данном случае я не буду описывать преимущества/недостатки и области применения этого паттерна, а попытаюсь изложить свой взгляд на его имплементацию в JAVA.

Общие сведения
Паттерн Singleton гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа.

Приветствую вас, хабралюди!

Взбрело мне в голову написать несколько статей, о том как реализованы некоторые структуры данных в Java. Надеюсь, статьи будут полезны визуалам (картинки наше всё), начинающим java-визуалам а также тем кто уже умеет писать new ArrayList(), но слабо представляет что же происходит внутри.



Сегодня поговорим о ArrayList-ах

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

XML

XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями. XML является упрощённым подмножеством языка SGML.

XML это удобная штука хранить файлы в читаемом виде.

Например простой XML файл может быть таким

Xpath — это язык запросов к элементам xml или xhtml документа. Также как SQL, xpath является декларативным языком запросов. Чтобы получить интересующие данные, необходимо всего лишь создать запрос, описывающий эти данные. Всю «черную» работу за вас выполнит интерпретатор языка xpath.
Очень удобно, не правда ли? Давайте посмотри какие возможности предлагает xpath для доступа к узлам веб-страниц.

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

Кроссворд, подсказки в котором — регулярные выражения.

Оригинал в PDF.

Автор — не я! Это часть MIT Mistery Hunt 2013.

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

В данной статье я расскажу о проблемах при покупке билетов РЖД и о том, как я пытаюсь их решать при помощи автоматизации действий в браузере.

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



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

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

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

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

Что?

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

Кто?

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

Зачем?

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

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

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

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

Мне очень нравится JavaScript и я считаю его мощным и удобным. Но для большинства начинающих JS-программистов, много проблем создаёт недопонимание аспектов языка. Часто конструкции языка ведут себя «нелогично». В данной статье я хочу привести примеры «граблей», на которые я наступил; объяснить поведение языка и дать пару советов.

Часто ли вам приходилось просматривать список изменений что бы понять — затронуло ли оно вас?
Хотели бы вы бегло просмотрев комментарий знать всю необходимую информацию?
Хочу поделиться сокращениями устоявшимися в нашей команде.

Тестирование и поиск ошибок – неотъемлемая и не самая интересная часть процесса разработки ПО. Для избавления себя от рутины этот процесс все стараются автоматизировать. И если для проверки функционала приложения создаются специализированные самодельные тесты, то поиск ошибок общего типа далеко не всегда ими покрывается. Проверяется ли, например, ваше приложение на наличие утечек памяти или гонок данных? В этой статье рассмотрим, как использовать обновлённый Inspector XE 2013 в двух ипостасях:

• Для регулярного автоматического тестирования (regression testing)
• Для ручного поиска причин проблемы в паре с отладчиком

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