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

Пример 1: на заправке Газпромнефть мне выдают 6 (шесть!) чеков.

Там стоит компьютер, терминал для карточек с принтером, второй отдельный принтер и другая техника.
Процесс выглядит незамысловато: в платежный терминал вставляют бонусную карточку, второй принтер что-то печатает, потом достают бонусную, вставляют кредитную, платежный терминал печатает чек, вставляют опять бонусную карточку, платежный терминал и принтер что-то печатают дуэтом, кассир собирает урожай, один из чеков оставляет себе, остальные 6 (шесть) отдаёт мне.
Вот скан чеков.

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

Пример 2: прорывной сервис онлайн покупки билетов РЖД.

Предисловие

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

Целевая аудитория, мотивация

Надеюсь, что пост окажется полезным для тех, кто на среднем уровне знаком с Git и на начальном — с Python. Кроме того, предполагается наличие базовых знаний об устройстве Unix-систем и регулярных выражениях.

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

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

Когда Ваш проект начинает пользуется популярностью и каждая миллисекунда обработки запроса от пользователя становится критической, приходится искать узкие места в системе. Часто больше всего времени занимает выполнение SQL запроса из приложения к базе данных. Попробуем разобраться, что можно оптимизировать в программе при работе с БД.

Не нашёл на хабре — спешу поделиться. Восхитительное выступление Александра Соловьёва ingspree на конференции JavaScript Frameworks Day 2013. На видео ниже просто набор отрывков из него, желающим посмотреть полностью — сюда.

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

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

Что такое платформер?

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

Одними из моих любимых игр данного жанра являются «Super Mario Brothers» и «Super Meat Boy». Давайте попробуем создать нечто среднее между ними.

Легкий и «полупраздничный» пост. Всех причастных с праздником :)

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

Несмотря на то, что PHP не является научным языком и редко используется в исследовательских целях, метод Монте-Карло легко может быть реализован и на нём. И в данной статье я покажу как это сделать.

Задача из реальной жизни

Пару дней назад у меня должна быть встреча в 9 часов утра, за 100 миль от моего дома. В 6.30 утра я проснулся, оделся и пока я завтракал, я начал прикидывать в блокноте ближайшие пару часов. Я, как обычно, хотел приехать вовремя, поэтому я начал набрасывать маршрут: выезд из города, проселочная дорога, затем по штату на север, на восток, местная дорога на восток, проехать город, затем на снова на север и прибытие в город. Все это выглядело как-то так:

Предисловие

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

Эффективные методы определения

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

В последнее время все больше говорят про «NoSQL» — прямо «модный» тренд образовался. «Технологию» начинают активно использовать известные авторитетные компании, в т.ч. в высоконагруженных проектах с немалыми объемами данных — и кто-то восхищается, а кто-то обливает себя бензином и факелом выпрыгивает с 35 этажа с криком: "SQL ACID forever!"


Причем о каком бы продукте не говорили, будь то MongoDB или Cassandra — нередко приходится наблюдать прямо таки религиозную восторженность и трепет, как будто речь идет о чем-то новом и священном.

Я нечасто играю в игры, а если и играю, то на PS Vita, которая не требует особых телодвижений для начала игры. Но периодически встречаю информацию об игровых устройствах, которые хотелось бы иметь в качестве дополнения в своем игровом «хозяйстве». Так вот, на днях встретилась новость о крохотном, если так можно выразиться, игровом ПК от Gigabyte, являющимся частью линейки Brix II. Этот компьютер по размеру очень невелик, и помещается в ладони взрослого человека. При этом разработчики позиционируют свой ПК именно как игровой, а не просто мини-десктоп. Стоит отметить, что длина ребра корпуса этого компьютера — всего 11,5 сантиметра.

Когда в 2007-м году представили iPhone, все, после 10-ти лет использовании Nokia и BlackBerry, были поражены огромным дисплеем телефона от Apple. Прошло 6 лет и сейчас уже 6.44-дюймовый экран с 1080p-разрешением кажется чем-то обычным.

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

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

• действия выполняются вручную, что требует сосредоточенности и аккуратности;
• жёсткие временные рамки.

В нашем случае налицо лимит по времени: релизы формируются, тестируются и выкатываются на продакшн-сервер два раза в день. При ограниченных сроках в жизненном цикле релиза процесс удаления (отката) из релизной ветки задачи, содержащей ошибку, имеет важное значение. Для её выполнения мы используем git rebase. Так как git rebase ― это полностью ручная операция, которая требует внимательности и скрупулезности и занимает продолжительное время, мы автоматизировали процесс удаления задачи из релизной ветки.

Здравствуй, Хабр.

Эта статья будет посвящена новому бизнес-флагману компании Nokia, Lumia 925, он же CatWalk в девичестве. И хотя в сети полно обзоров, сравнений и описаний подобных устройств, думаю, мой альтернативный тест будет интересен, а также позволит, как мне кажется, немного разгрести поломанные копья о мобильную фотографию.

Введение

Что здесь будет и чего не будет. По моему опыту чтения обзоров телефонов они на 80-90% состоят из описания того, что находится в коробке, как аппарат лежит в руке, как слышно собеседника и описания пунктов меню. Перечислять очевидное мне не хочется, поэтому такие темы как эргономика, качество связи, питание, установка приложений в обзор не войдут. Любой может зайти в салон связи и оценить эти параметры за время меньшее, чем требуется на прочтение статьи. Обзоры телефонов часто дополняют фото, сделанные из окна тестера, со стола тестера и с автобусной остановки тестера. Эти изображения отличаются малой информативностью, плохим освещением, часто отсутствием композиции. Все это зачастую мало говорит о возможностях камеры и программного обеспечения. В своем обзоре я постараюсь провести максимально объективный тест камеры Nokia Lumia 925.

Полгода назад написал бандл ClosureTable для фреймворка Laravel 3. Поводом для написания стала вот эта замечательная презентация Билла Карвина о способах хранения и обработки иерархических данных в MySQL с использованием PHP.

Итак. Существует несколько шаблонов проектирования баз данных для хранения и обработки иерархических структур:

• Adjacency List («список смежности»)
• Materialized Path («материализованный путь»)
• Nested Sets («вложенные множества»)
• Closure Table («таблица связей»)

Представьте на минутку, что вы — недавно принятый на работу программист, которому предстоит работать с популярной системой управления обучением (LMS) Hot4Learning. Ваш предшественник когда-то поработал над добавлением к системе возможности отправки email — для того, чтобы любой пользователь в школе мог отправить другому пользователю электронное письмо с помощью веб-интерфейса. Но, увы, судьба оказалась к нему неблагосклонна — его сбил автобус, и он так никогда и не завершил свой magnum opus, свою лебединую песню. Ваша задача — довести его дело до конца, добавив функцию валидации введенного email — чтобы можно было быть уверенным, что письма отправляются только в том случае, когда в качестве адресата вводится правильный адрес, привязанный к школе.

Приведем конкретный пример: допустим, Боб — студент в Университете Макгилла, и он должен иметь возможность отправить письмо на любой валидный адрес @mail.mcgill.ca или @mcgill.ca. Если адрес его подружки Джейн выглядит как jane.smith@mail.mcgill.ca, то тогда Боб имеет полное право отправлять на него письма. В другом случае — скажем, если ее адрес jane.smith@mail.ru — он, понятное дело, права на это не имеет, как и на отсылку писем на адрес thisisnotavalidemail@mail.mcgill.ca.

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

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

После нескольких часов чтения обзоров, Боб с нетерпением нажал на кнопку перехода к оформлению заказа на галлон цельного молока, и…
Воу, что только что произошло?

По долгу службы мне досталась в наследство некая система, имеющая ~15 лет истории и порядка нескольких десятков инсталляций в разных организациях. Сама по себе системы относительно небольшая (~25K строчек кода, ~1K коммитов), но проблема была в release management:

• было основное дерево в subversion (изначально в cvs, разумеется), где проводился «основной курс партии» — делались какие-то масштабные изменения, добавлялись новые возможности, исправлялись глобальные ошибки и т.п.
• конкретные инсталляции делались путем:
  
  • в лучшем случае — svn checkout, который потом обновлялся через svn update; почти во всех инсталляциях делались локальные доработки «на живую» (как минимум — правились конфигурационные файлы) и эти изменения никуда не коммитились; если при очередном svn update изменения в upstream создавали конфликт — конфликт ресолвился «на месте» тем программистом, который делал update, опять же, без какого-либо трекинга изменений
  • в худшем случае — svn export, который потом, понятно, не обновлялся совсем, оставаясь раз и навсегда (или по крайней мере пока начальство не одумается) на уровне развития даты экспорта; в особо запущенных случаях (из конца 1990-х — начала 2000-х) так делали еще и потому, что просто не было физической возможности сделать checkout — в организации не было доступа в интернет, архив просто приносили на дискетке и разворачивали единожды на месте

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

Примечание переводчика: После публикации статьи с автором связался коммерческий директор из King.com, создателя Candy Crush Saga, и прояснил несколько моментов, после чего автор добавил пару замечаний. Добавленные абзацы отмечены курсивом.

Принудительная монетизация

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

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

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