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

Вообще, чем мне не нравится Adjacency List, так это рекурсией, особенно, когда нужно выбрать дерево, без каких либо ограничений, например:

• Все дерево комментариев;
• Карта сайта;
• Навигационное меню;
• и т.д.;

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

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

Общая информация

Так как мобильных устройств существует великое множество, то одна модель может поддерживать какие-либо возможности HTML/CSS, а другая наоборот — либо не поддерживать, либо поддерживать неправильно.

Но большинство устройств среднего и уж тем более hi-end класса поддерживают HTML/CSS в той или иной степени. Таким образом, язык WML для разработки сайтов под мобильные устройства устарел и практически не используется. На смену ему постепенно приходит общепризнанный стандарт в разработке сайтов — XHTML/CSS. Кодировка — строго UTF-8 (No BOM).

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

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

Сейчас мы попробуем провести нашего «сферического айтишника в вакууме» через «информационный» закон, выделив в нем наиболее важное.

Программа и данные

Здравствуй, хабрачитатель.

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

Маркетинг магазина в реале начинается с выбора места. Есть два пути решения задачи: так называемый «жоп-филинг», то есть интуитивное принятие решения и продуманный просчёт.

Общая задача такая:

• Есть интернет-магазин, нужна точка в реале;
• Место должно способствовать наибольшей прибыли точки как отдельного розничного магазина;
• И хорошо работать как пункт самовывоза интернет-магазина.

При разработке одного проекта встала задача – определить по IP-адресу посетителя его страну и город, на русском языке. Поиск готового решения оказался безуспешным – русскоязычные базы стран можно найти (например, wipmania.com), но баз городов нет. Помощь пришла из-за границы, в лице англоязычного maxmind.com. База была приведена к нормальному состоянию (MySQL) и частично переведена на русский язык с помощью нескольких справочников (~6,000 названий, с учетом городов-тезок ~15,500).   Результат этой работы доступен для свободного скачивания.

В интернете достаточно много информации на данную тему, но, несмотря на это, многие обходят её стороной. Цель данного поста, разъяснить на пальцах основы взаимодействия с Memcached.

В этой статье я опишу принципиальные различия Apache и Nginx, архитектуру фронтэнд-бэкэнд, установку Apache в качестве бэкэнда и Nginx в качестве фронтэнда. А также опишу технологию, позволяющую ускорить работу веб-сервера: gzip_static+yuicompressor.

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

1. Почему не mb_detect_encoding() ?

Если кратко — он не работает.

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



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

В продолжение статьи Евгения Ческидова «Яндекс. Директ. Анализируем конкурентное окружение» я хочу показать, как при помощи не очень сложных расчетов и API Яндекса вытащить из Директа буквально всю информацию о рекламных кампаниях конкурентов. Сразу скажу, что идея на практике еще не проверялась, сам факт наличия всей информации и, соответственно, возможности этого расчета был показан Ческидовым только вчера, а алгоритм родился буквально сейчас. Но математически вроде бы всё сходится. Осторожно, под катом много формул.

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

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

Статья посвящена основам и является детальным их описанием. Следующие статьи с подробными примерами будут основываться на ней. Данная статья построена на принципах, которые мы обсуждали в «Где наша бизнес-логика, сынок?» («Dude, where's my business logic?»).

Привет всему хабросообществу.

Время не стоит на месте. После публикации моего справочника по Postgresql очень многое успело поменяться, а точнее добавиться в эту отличную СУБД. После выхода PostgreSQL 9 версии я понял, что потребуется добавить информацию о нововведениях для этой версии. Тем более, что 9 версия знаменуется выходом репликации из коробки.

Введение

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

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

Тем не менее, задача «хранить деревья в базе данных» рано или поздно возникает перед любым разработчиком.

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

О скруглении углов в html-верстке сказано уже столько, что я пойму тех кто прочитав заголовок иронично улыбнется и подумает «опять 25, ну сколько можно...». Поэтому я постараюсь кратко изложить суть, и сразу предупрежу, что этот метод вы едва ли могли видеть раньше.

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

Мы делили апельсин, много нас, а он один

В американской традиции стартапов принято брать в долю всех участников проекта, работающих с первого дня его основания. Отличный способ мотивации команды, скажу я вам. Но как делить баснословные доходы, если они таки будут? Самое первое, приходящее на ум — поделить поровну. Таким образом, если над стартапом работало пять человек, то каждому достанется по 20%. Справедливо? Не очень.

У американцев есть отличная поговорка про курицу и свинью «a chicken is involved with breakfast, but a pig is committed»: речь о яичнице с беконом на завтрак, для приготовления которого требуется некоторое усилие от курицы (снести яйцо и жить себе спокойно дальше), в то время как свинье придётся принести куда более существенную жертву. Так же и в бизнесе: некоторые участники проекта выполняют работу достаточно формально и потом наблюдают за результатами, другие же несут принципиально большие риски и вкладываются в дело сильнее.

Frank Demmler, профессор предпринимательства в бизнес-школе при Carnegie Mellon University, предложил следующий метод распределения долей в стартапе.

Вместо введения

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

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