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

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

Страница проекта на Кикстартер — (Kickstarter link page)
Страничка проекта на Фейсбуке — (Facebook game page)
Официальный сайт разработчика After Reset Official web-site
Гейм-плейное видео на Youtube Video-link
Эксклюзивное видео снятое специально для Хабра на Vimeo Video-link

Так уж получается, что под Новый Год разработчики начали выбрасывать на Кикстартер проекты один краше другого. Если честно – не знаешь, о каком из них писать первым. Их действительно много, и многие из них достойны огласки. Сегодня мне хочется остановить наше внимание на проекте After Reset. Также мне подумалось, что будет хорошей практикой брать интервью у разработчика, по возможности с эксклюзивными материалами. Все-таки Хабр, крупнейший российский IT-ресурс, как тут обойтись без редких артефактов?



Если кратенько, — это еще один проект, претендующий на пьедестал нашего любимого пустынного изометрического друга с блек-джеком и сами знаете кем. Претензия серьезна столь, что впору усомниться. И я усомнился. И не стесняюсь этого. Сомневаюсь, кстати, даже после того как ознакомился с редкими публикациями в сети, видео и даже погонямши билд для прессы (именно с этой версии и сняты скриншоты). Выглядит блюдо отменно. Особенно на фоне Пустынного Гамбургера. Откуда же сомненья?

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

Quick Help научился брать документацию из комментариев:

Если вам, как и мне, время от времени приходится пользоваться SSH, то вы оцените небольшое дополнение для OS X, разработанное Тревором Фитцжеральдом — Shuttle. Оно позволяет повесить быстрый доступ к нужным хостам на иконку в верхней панели.

Скачать приложение можно по ссылке http://fitztrev.github.io/shuttle/

Доброго времени суток. Вышла первая стабильная версия нового шаблонизатора Fenom. Для нетерпеливых, Fenom — это легковесный (статистика прилагается), быстрый (бенчмарк прилагается), гибкий (API прилагается) шаблонизатор, который может стать удачной заменой шаблонизаторам Twig или Smarty.

Существует полезный и нужный инструмент для мониторинга PHP под названием pinba. Он позволяет собирать статистику по выполнению PHP-скриптов вашего проекта. Мы реализовали небольшую систему, которая дополняет Pinba, и назвали ее Pinboard (Pinba board).

Суть работы

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

Как часто Вы используете конструкции вида «5 минут назад», «Полчаса назад» на вашем сайте? А что если пользователь открыл вкладку и забыл про нее на пару часов? «5 минут назад» явно теряет свою актуальность.
Именно для того чтобы исправить это досадное недоразумение служит uptodate.js

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

Бывают ситуации когда документы имеют много различных полей и необходимо иметь эффективные запросы по ним. Например есть документ описывающий человека:

{
    _id: 123,
    firstName: "John",
    lastName: "Smith",
    age: 25,
    height: 6.0,
    dob: Date,
    eyes: "blue",
    sign: "Capricorn",
    ...
}

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

Наша компания занимается разработкой web-приложений на заказ. Не сайтов-визиток, а именно приложений. Чаще всего — для внутрикорпоративного использования.

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

В недавнем времени на кикстартере стартовал проект «бюджетного» 3D принтера — RigidBot 3D Printer предлагающий качественный и дешевый вариант 3d-печати для дома или офиса. В лучших традициях краудфандинга, в первые 12 часов запрошенная сумма ($31.500) была превышена на порядок и, на текущий момент, подбирается к отметке в $500.000.



И хотя, очередным 3D-принтером никого не удивишь, все же стоит выделить пару интересных особенностей данного проекта:

Как известно, «голый» GPS во время холодного старта без внешней помощи получает координаты за 3-12 минут. Так получается из-за того, что набор данных с координатами спутников передается каждым спутником 12.5 минут. Принимая одновременно данные с нескольких спутников это время можно уменьшить, но оно все равно достаточно большое.

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

Обычно проблемы со скоростью захвата GPS координат пытаются решать редактированием файла gps.conf (что требует рутованого телефона) — там например могут быть указаны нерабочие NTP сервера. Но что если мобильного интернета нет вообще?

Здравствуйте, уважаемое Хабрасообщество!

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

Долгое время я использовал Twitter Bootstrap, но он не мог удовлетворить все потребности. Приходилось верстать дополнительные кнопочки и писать скрипты. Но вот однажды, я познакомился с замечательным UI-фреймворком KendoUI от Telerik. Что из этого получилось под катом.

В недавнем дайджесте интересных ссылок о PHP я обнаружил ссылку на комментарий Никиты Попова на StackOverflow, где он подробно рассказывает о механизме «под капотом» управляющей конструкции foreach.
Поскольку foreach действительно иногда работает более, чем странным образом, я счел полезным сделать перевод этого ответа.

Внимание: этот текст подразумевает наличие базовых знаний о функциональности zval'ов в PHP, в частности вы должны знать что такое refcount и is_ref.
foreach работает с сущностями разных типов: с массивами, с простыми объектами (где перечисляются доступные свойства) и с Traversable-объектами (вернее, объектами, у которых определен внутренний обработчик get_iterator). Здесь мы, в основном, говорим о массивах, но я скажу и об остальных в самом конце.

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

Перевод этой статьи уже есть на хабре, но он ужасен и содержит ложную информацию.

Приветствую, искатели приключений! Путешествуя по территории индексации MongoDB хотя бы некоторое время, вы, возможно, познакомились с таким правилом: если ваш запрос содержит сортировку/порядок (orderby) – добавьте сортируемое поле в конец индекса который используется для запроса.

Во многих случаях когда запрос содержит равенство (то есть поиск конкретного значения, например, {“name”: “Charlie”}) данная мантра бывает весьма полезной.

Запрос

db.drivers.find({"country": {"$in": ["A", "G"]}}).sort({"carsOwned": 1})

Индекс

{"country": 1, "carsOwned": 1}

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

Слишком часто стала мелькать в западных блогах и твиттере аббревиатура “DCI”. Меня удивил тот факт, что на хабре по данной тематике почти нету информации, лишь в Ruby NoName Podcast S04E09 упоминалось об этом. Любопытство взяло вверх, и я решил узнать об этом загадочном слове побольше. В процессе поиска я наткнулся на хорошую статью, написанную на английском моим земляком, Виктором Савкиным. Данная статья без обильной теории, на практических примерах показывает, что из себя представляет DCI. Далее повествование будет идти от лица Виктора.

Для перемещения элемента по экрану есть два основных способа:

• CSS 2D-преобразования и translate();
• position:absolute и изменение top/left.

Крис Койер недавно писал, почему лучше и логичнее использовать translate (это быстрее, и свойство position имеет большее отношение к вёрстке, а не к визуальным эффектам и анимации, в отличие от translate).

Я хочу расширить его ответ и привести несколько хороших примеров. Я записал скринкаст, в котором помощью Chrome DevTools timline рассматриваю различия между этими подходами с точки зрения производительности, особенностей рендеринга и композитинга на GPU.



Если вам нужна сокращённая текстовая версия — продолжайте читать.

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

Есть задачи, которые в рамках реляционных СУБД не имеют универсальных решений и для того чтобы получить хоть какой-то приемлемый результат, приходится придумывать целый набор костылей, который ты потом гордо называешь “Архитектура”. Не так давно мне как раз встретилась именно такая.

Предположим, имеется некоторые сущности А и Б, связанные между собой по принципу One-to-Many. Количество экземпляров данных сущностей достаточно велико. При отображении сущностей для пользователя необходимо применить ряд независимых критериев, как для сущности А так и для сущности Б. Причем результатом применения критериев являются множества достаточно большой мощности — порядка нескольких миллионов записей. Критерии фильтрации и принцип сортировки задается пользователем. Как (я бы ещё спросил: Зачем им миллионы записей на одном экране? — но говорят надо) показать все это пользователю за время 0 секунд?
Решать такие задачи всегда интересно, но их решение сильно зависит от СУБД, под управлением которой крутится твоя база данных. Если у тебя в рукаве козырной туз в виде Oracle, то есть шанс, что эти костыли он подставит сам. Но спустимся на землю — у нас есть только MySQL, так что придется почитать теорию.

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

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

Допустим, эта часть Вам понравилась и Вы задумались о том, чтобы перейти в этот проект. Потенциально Вам с этими людьми работать следующие несколько лет (ну минимум — месяцев). Поэтому имеет смысл пораспрашивать о проекте поподробнее. А заодно и будущих сокомандников прощупать — что они за перцы? ;)

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