Доброго времени суток дорогой %username%!
Хотелось бы поздравить с праздником всех админов и в честь этого накатило на меня написать пост. По роду своей деятельности (*nix админ), ко мне обращаются знакомые с различными просьбами о помощи по серверам. Обычно просьбы в духе — у нас стал тормозить сайт, или что-то у нас повисло и т.п. Очень часто, проблемы возникают из-за действий программистов, которые не всегда понимают что делают, либо не понимают последствий того, что они делают. Посмотрев на это все, я решил поделиться с вами некоторыми случаями и наставлениями.

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

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

В моём детстве огромную роль играли книги. У моих родителей (тогда ещё молодых инженеров) было много книг — приключенческие романы, детективы, фантастика, техническая и научная литература. У отца была подшивка журналов «Юный техник» и «Изобретатель и рационализатор» за полтора десятилетия. Книга или журнал в нашем доме всегда были чем-то очень важным. Дело было даже не столько в том, что в 80-90-ых их было не так легко достать, как во внимании, с которым мои родители их читали, обсуждали, что-то пересказывали мне. А ребёнок ведь в любом случае наследует поведение родителей, их интересы. И я зачитывал до дыр технические журналы, легко «глотал» детскую фантастику Булычева и Гаррисона, чуть поднапрягшись — и более серьёзных Брэдбери и Шекли. Городская библиотека, откровенно презираемая большинством моих сверстников, видела меня 2-3 раза в неделю почти десятилетие. Во многом мой жизненный путь, интерес к науке и технике, был определён уже тогда. Думаю, если бы в моём книжном шкафу 20 лет назад не стояли «Аэлита» Толстого, «Машина времени» Уэллса и «Я, робот» Азимова, я не писал бы сейчас на Хабре эту статью (и сотню предыдущих), а протирал бы штаны где-нибудь на должности «менеджера среднего звена по перекладыванию из пустого в порожнее».

Сегодня на дворе 2014 год и вот уже мой ребёнок учится читать по слогам. Завтра он протянет руку к книжному шкафу. Что же он возьмёт — бумажную книгу или электронную? Что это будет за книга?

Ценник должен быть с печатью или подписью. Он является документом и обязательно должен быть на товаре. Если вы видите что-то с ценником (неважно, где и как оно стоит), вы имеете право купить его по цене на нём.

Пример: вам говорят, что товар по акции кончился. Вы видите один в витрине в герметичном ящике под потолком, но с ценником. Вам не имеют права отказать в его продаже.

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

… а именно как писать LL парсеры для не очень сложных структур при помощи конструирования сложного парсера из более простых. Изредка возникает необходимость распарсить что то несложное, скажем некую XML-подобную структуру или какой нибудь data URL, и тогда обычно возникает либо простыня хитрого трудно читаемого кода либо зависимость от какой то ещё более сложной и хитрой библиотеки для парсинга. Здесь я собираюсь совместить несколько известных идей (какие то из них попадались на Хабре) и показать как можно просто и лаконично написать довольно сложные парсеры уложившись при этом в совсем немного строчек кода. Для примера я буду писать парсер XML-подобной структуры. И да, я не буду вставлять сюда картинку для привлечения внимания. В статье вообще картинок нет, поэтому читать будет трудно.

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

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

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

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

Мне захотелось «поиграть» с технологией, и в то же время не ввязываться в разработку. Для этого я решил найти готовые решения, которые позволяют без программирования построить iBeacon-приложения.

Я получил доступ и потестировал несколько платформ, о которых и расскажу в этой статье.

Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

Если вы работаете над Node.js приложением, то есть все шансы, что у него появится некое API, которое будет использовано вами или кем-то другим. Наверняка это будет REST API и перед вами возникнет дилемма — какие инструменты и подходы использовать. Ведь выбор так широк…



Благодаря невероятно активному сообществу Node.js, количество результатов на NPM по запросу «rest» зашкаливает. У каждого есть свои реализации и подходы, но у некоторых есть что-то общее в создании REST API на Node.js.

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

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

• BEM
• Собственно пример — как сверстать страницу

iBeacon, анонсированная Apple в недавнем прошлом технология микро-навигации и микро-позиционирования. iBeacon представляет собой небольшой (размером с монету) девайс, выполняющий функцию маяка. Конкретнее, транслирует через Bluetooth Low Energy сигнал со своим уникальным идентификатором. Сигнал маяка обнаруживается смартфоном с возможностью определения расстояния до него. Дальность обнаружения в зависимости от модели маяка достигает 50-70 метров. Маяк работает автономно от батарейки, которой хватит от полугода до двух, а то и до трех лет.

Возможные области применения ограничены только фантазией:

• in-door навигация в торговых центрах, на выставках и конференциях;
• in-place информация и специальные предложения для посетителей торговых сетей;
• смартфон — экскурсовод в музеях;
• смартфон — ключ от квартиры, автомобиля, номера в гостинице или пропуск в офис.

Вдохновившись этими перспективами, я решил параллельно с маркетинговым анализом «пощупать» технологию своими руками, и заказал несколько пробных экземпляров.

Хей народ, пристегните ремни и держитесь покрепче, ибо наступил действительно волнительный момент: вам предстоит разобраться в тонкостях чрезвычайно интересных временных функций CSS!

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

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

Метод 1. Фотографии пользователей с товаром

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

Совет – например, покажите ваш товар в естественной обстановке с теми людьми, которые им пользуются. Вот как это делаем мы:



За 5 лет работы у нас образовался достаточно большой архив фотографий настолок с играми. Мы их и использовали. Вы можете сделать практически то же самое. Да! Есть нюанс. Если ваши покупатели – дети, то никогда не ставьте фотографии с более младшими «пользователями»: гораздо лучше — постарше. Всё просто. Ребёнок хочет быть похожим на старших и совершенно не хочет – на «малышей».

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

Условно проблема выглядит вот так:

###
My awesome class
###
class Awesome
  doFoo : (arg, cb) ->
    unless arg is 42
      return cb Error """
                      only The Answer may be an argument, but got:
                      |arg| = |#{arg}|
                      """
    cb null, "#{arg} is The Answer"

  doBar : (arg, cb) ->
    # hm... arg must be The Answer too

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

Как известно, CoffeeScriptпредлагает несколько иной набор управляющих конструкций, нежели JavaScript.

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

Доброго времени суток уважаемые хабравчане. На просторах интернета мне повстречался один миниатюрный и очень интересный Bash скрипт. С помощью ImageMagick он потрясающим образом обрабатывает фотографии белой учебной доски, очищая «содержимое» от всего лишнего:

#!/bin/bash
convert $1 -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 $2

До:

После:

Вступление

Возможность асинхронной работы с помощью callback-функций(далее просто возвращаемых функций) — отличительная особенность JavaScript. Использование асинхронных возвращаемых функций позволяет вам писать событийно-ориентированный код, но так же добавляет кучу проблем, ведь код перестает выполняться в линейной последовательности.

К счастью, теперь в Chrome Canary DevTools вы можете отслеживать весь стек вызовов асинхронных функций в JavaScript!

Привет Хабр!

Изначально хотел назвать статью «HTML по ГОСТ`у», но потом выяснилось что у большинства программистов не было предмета «Метрология и стандартизация» и о «стандартизации», «сертификации», «унификации» не все слышали.

В i-Free я много занимаюсь разработкой веб-приложений. А поскольку их много, они разные и работают в разных условиях, то само собой приходится задумываться о стандартизации. Есть такой проект «Пуленепробиваемый HTML5» (http://html5boilerplate.com/), в котором разработчики решили создать идеальный шаблон странички. Он мне очень нравился, и все свои проекты я начинал именно с него. Но, исправляя баг за багом, делая все новые и новые приложения, я пришел к выводу, что многого в нем не хватает. В этой статье я хотел бы рассказать о том, что обычно пропускают при написание страничек и веб-приложений и показать, чем и зачем я прокачал свой шаблон пустой странички.

На Хабре не раз поднимался вопрос автодополнения адресов в форме (раз, два, три).

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

• Автодополнение адресов только Москвы
• Автодополнение адреса одной строкой
• Решение должно быть бесплатно (лимит запросов не менее 1000 в сутки)
• Возможность подключить без дополнительных JS библиотек. (Я использую AngularJS Bootstrap-UI, в котором есть директива Typeahead, реализующая автодополнение формы)
• Стопроцентный uptime не обязателен

Но какой источник данных выбрать? Я выбрал целых четыре, и решил их сравнить: в одном углу ринга заморские Google Geocode и Google Autococomplete, а в другом отечественные КЛАДР в облаке и DaData подсказки.

DISCLAIMER: Автор никак не причастен к разработчикам ни одного из представленных сервисов.

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