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

Встала проблема загрузки заранее посчитанных данных в программу поиска пути между двумя точками (не важно какую). Проблема встала настолько сильно, что загрузка просчитанных данных стала занимать 90% всех последующих расчётов.
Мои данные — двухмерный массив, состоящий из 200 на 200 ячеек примерно.

Тестирую unserialize, json_decode

с буквенными ключами
json_decode — 0.080sec
unserialize — 0.072sec

только цифровые ключи
json_decode — 0.041 sec (170kb)
unserialize — 0.037 sec (500kb)

Сам маршрут ищется за 0.0004-0.0012 sec :)
Значит, надо ещё что-нибудь придумать.

Ваш проект это пьеса (надеюсь что не трагедия)



Какая цель вашей пьесы?
Цель — сделать счастливым заинтересованных лиц.
Meet stakesholders expectations.

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

Ваша работа это «make everyone a winner» [Boehm, 1989]. До тех пор пока происходит то, что ожидается — все счастливы. Наш CEO, умный дядька в очках, постоянно говорит: all you need is to make the customers happy. Он о заказчиках, вам же нужно думать и обо всех других.

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

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

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

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

Хабраюзер afan в своём топике Идея: функция форматирования для удобной локализации строк предложил интересную концепцию. Какой собственно я решил воспользоваться в своём движке.

И так,

Начал замечать что на Хабре появляются статьи по программированию, может на это натолкнули фразы типа «хабр уже не тот», но это не так важно, потому как мне это нравится, всегда хотелось узнать что-то новенькое … моя первая статья привела к огромному краху, поэтому почитав людей, я повторю свои усилия и начну цикл заметок о JavaScript от самого начала и до тех пор, пока это будет востребовано =)

До того как заняться верской гитарных аккордов (статьи 1,2,3) я столкнулся с необходимостью сделать человеку на сайте меню-дерево. Рисовать не хотелось вообще, поэтому я взял старый добрый HTML с CSS и начал делать это дерево, начал с простого одноуровневого, а позже сделал многоуровневое с маркерами, которое и представлю.

Позже это дерево дало мне плоды в виде habrahabr.ru/blogs/css/53792

На волне интереса к NetBeans расскажу небольшой хинт. Я работаю в основном с CodeIgniter, и вот чего мне сильно не хватает в IDE это быстрого автодополнения для встроенных функций (библиотек, хелперов) — вроде $this→form_validation→…

Сейчас я расскажу, как это реализовать:

Проблема: при переводе приложений на другие языки (чаще мы сталкиваемся с русификацией англоязычных продуктов) чаще всего страдает поддержка множественных форм чисел. Например, «1 заметка, 2 заметки, 5 заметки» или якобы универсальное «1 file(s)» и т.д. Дело в том, что во всех языках программирования обычно дело не идет дальше варианта sprintf() или какого-то шаблонизатора, а поддержку множественных форм надо каждый раз программировать ручками: если N = 1, то «1 заметка», иначе «N заметок». А делать это каждый раз лениво. Эту задачу частично решает фреймворк gettext, где есть понятие нескольких вариантов локализованной строки, но это не сильно облегчает жизнь, ибо в одной строке, показываемой пользователю, может быть несколько частей, зависящих от чисел («Найдено 23 файла в 3 папках»), а значит куски строк надо потом все равно склеивать между собой.

Поэтому мне пришла следующая идея: почему бы не придумать какой-то общий формат, микроязык (по аналогии с вполне устоявшимся форматом функции format() или sprintf()), чтобы адресовать эту проблему и упростить в дальнейшем написание локализуемого кода.

Как известно, в разных языках разное количество множественных форм числа. В английском их два («1 file», «many files»). В русском — три («1 файл», «2 файла», «много файлов»). В арабском их вообще, как говорит нам Pootle, аж 6 штук. Поэтому нам нужно иметь возможность задавать прямо в строке набор из нескольких подстрок и параметр, от которого зависит выбор этих подстрок.

Предлагаемый формат подстроки с множественными вариантами:
{%COUNTER%|FORM0|FORM1|FORM2[|FORM3][|FORM4][|...]}

где
%COUNTER% — это некое имя переменной, которое может иметь значения [0,1,2,3,...]
FORM0 — это версия строки для значения COUNTER = 0 (это особый случай, обычно требующий отдельного сообщения)
FORM1, FORM2 и т.д. — это альтернативные варианты текста для каждой множественной формы данного языка; для английского это будет два варианта, для русского — три и т.д.

Пример на английском языке:
{%F%|No files|1 file|%F% files} found in {%D%|0 folders|1 folder|%D% folders}.

Это даст нам следующие конечные варианты строки на выходе при подстановке различных значений %F% и %D%:
%F% = 0, %D% = 1 => No files found in 1 folder.
%F% = 1, %D% = 2 => 1 file found in 2 folders.

Тот же пример строки, переведенной на русский:
{%F%|Не найдено файлов|1 файл найден|%F% файла найдено|%F% файлов найдено} в {%D%|0 папках|1 папке|%D% папках|%D% папках}.

Это даст нам следующие конечные варианты строки на выходе при подстановке различных значений %F% и %D%:
%F% = 0, %D% = 1 => Не найдено файлов в 1 папке.
%F% = 1, %D% = 2 => 1 файл найден в 2 папках.

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

Было бы здорово иметь реализацию подобного микроязыка на разных языках программирования.

Надеюсь, кому-нибудь идея пригодится.

UPD: Результат не заставил себя долго ждать: в данном топике хабраюзер webdew делится реализацией функции на C#, за что ему большое спасибо.

По мотивам статьи dmalinovsky «Жизнь во фрилансе глазами программиста».

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

В наше время в сети достаточно легко найти «12 правил фрилансера», или «20 советов фрилансеру», а то и «библию фриланса».
У всех разное отношение к этому явлению, разный опыт или предубеждения. Немало, кстати, негативных мнений.
Мне бы не хотелось писать очередное руководство «как заработать 10000$ в месяц». Поделюсь своим небольшим, но положительным опытом в роли «Фрилансера» и кое-какими выводами. Этот опыт сделал для меня работу на фрилансе комфортной и прибыльной.

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

Испокон веков, с тех самых пор, когда были осуществлены первые успешные проекты, считалось, что критериев успеха три. Вовремя. Качественно. Недорого.

Кстати, а вы знаете, что первыми упешными руководителями проектов были египтяне? Именно в честь их пирамид, треугольных в профиль, ограничения проекта по срокам, качеству и бюждету назвали “Золотым треугольником”.

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

В принципе, даже подготовку корпоративной попойки можно считать проектом.

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

Друзья!

Состоялся второй семинар для стартапщиков от проекта Egenius.ru. Тему обсуждали следующую: «Управление командой стартапа». Сразу хочу извиниться за срыв онлайн-трансляции. На площадке отрубился интернет. Но все-таки было много интересного. Дима Браверман (SmartContext) давал практические советы, Юра Синодов рассказывал, как он запускал стартап Roem.ru в офисе «класса G» в компании с программистом-бездельником и помощником программиста — юным алкоголиком. Видеозапись семинара и презентации докладчиков можно посмотреть/скачать здесь
А также мне показались весьма полезными советы Дмитрия по управлению командой, посему я решила ими поделиться с общественностью.
Итак,

Про сроки:

* Определяя сроки проекта, время, необходимое для решения задачи, которое Вам назвал программист, умножайте на 2. То, что говорит дизайнер – на 3.
* Если задача требует слишком много времени для решения, подумайте, нельзя ли от этой задачи отказаться.
* Даже если Вам в голову пришла гениальная идея — не спешите ее реализовывать. Сначала просчитайте, каких именно ресурсов потребует ее решение, а затем впишите в план следующего релиза проекта

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

Навеяно последними спорами на Хабре "Программирование — отстой" vs "Программирование — не отстой".

Год назад я готовил материалы по очень близкой теме, однако вижу, что тема до сих пор не потеряла актуальность, а потому попробую ещё углубить тему «программирование <> отстой», несколько с другой стороны.

Рекомендую предварительно прочитать статью Михаила Донского "жизненный цикл профессии программиста", который даёт более чем 60-летнюю ретроспективу профессии программиста и показывает некоторые особенности (по большей части психологические) современного поколения программистов.

Ну а теперь, собственно, тезисы:

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

Перевод статьи из блога Enfranchised Mind.

Недавно мне на глаза попалось два текста, на которые я просто не мог не ответить. Первый, самый ужасный, — это статья на Daily WTF «Программирование — отстой! Или что-то вроде того». Второй — пост о том, почему функциональное программирование не получает распространения.

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

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

Наибольшие трудности при построении сайтов c применением AJAX возникают при реализации механизма AHAH (Asynchronous HTML and HTTP). Особенно выполнение на лету подгружаемых Javascript-ов. Также есть куча дополнительного «гемороя» при разработке AJAX сайтов и веб-приложений. Вы можете ознакомится с детальным описанием некоторых существующих проблем. Из-за указанных сложностей, многие разработчики отказываются от более насыщенного внедрения AJAX.

Однако, мало кто знает, что перечисленные проблемы можно решить.

Пост написан от некоторого отчаяния. Дело в том, что общение по рабочим вопросам с людьми (с клиентами, партнёрами, исполнителями) стало потреблять слишком много моих ресурсов (времени, внимания). Более всего утомляют инструменты общения, выбранные моими собеседниками.

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

Телефон, Skype и прочие VoIP

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

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

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

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

Телефонные звонки не оставляют логов. Максимум, что обычно можно узнать о прошлых звонках: кто, кому, когда звонил. И совсем ничего относящегося к содержанию разговора. А содержание важно хотя бы даже для последующего разбора полётов.