В продолжение темы: раз, два, три, четыре.

Сразу скажу, что подход к разгорающемуся холивару «время vs. деньги» (а точнее к вопросу управления личными ресурсами), которого я придерживаюсь, позаимствован мной из вебинара, выложенного в записи на сайте datnews.ru, а автор этого сайта скорее всего позаимствовал его у Тима Ферриса или еще какого-нибудь гуру лайф-менеджмента, и в принципе является самоочевидной истиной, которую, однако, почему-то мало кто способен правильно усвоить и использовать.

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

Дано: заказчик за рубежом, желающий работать с Вами и платить вам евро или доллары.
Найти: оптимальный способ организовать работу с ним, чтобы платить налоги и спать спокойно.

Сразу скажу, что получение денег на пластиковую карту без уплаты налогов может вылиться в серьезные проблемы (про ответственность написано в конце топика). Объяснения, что деньги «от бабушки внучку на мороженное» при суммах больше 10К$ в год уже не прокатывают, особенно если в реквизитах «бабушки» будет стоять что-то вроде «GMBH Star Development» Вероятность того, что возьмут за задницу достаточно высокая и поэтому лучше не рисковать и делать все по Закону, тем более, что ничего сложного в этом нет

После публикации ряда заметок на тему сжатия и объединения JavaScirpt-файлов стоит все же осветить наиболее характерные проблемы этого самого сжатия и объединения.

Начнем с простого: как JS-сжатие способно испортить нам настроение. И как его поднять обратно :)

UPD стартовал конкурс ускорения сайтов. В призах: монитор, веб-камера, мышь. Все гипер-быстрое.

-О чём вы, Морфеус?

Количество фреймворков в мире растёт с пугающей скоростью. Тысячи их уже на данный момент. Благо, лучших из низ — не так много. Весь мир Web разработчиков просто подразделился на несколько групп, которые отадют предпочтение тому или иному фреймворку. Я не люблю тёрок и холиваров, так что бог с ним с тем, что лучше. Я лишь хочу поговорить с разработчиками ASP.NET о Ruby on Rails.

Зачем?

Расскажу свою историю. На ASP.NET я пишу с 2004 года. Знаю множество закоулков данной системы и знаю, что она сама по себе восхитительна. Я пережил 3 больших проекта на .NET и написал с 10 сайтов, которые сейчас продолжают стабильно работать. Если говорить о фрейворкнутости, то .NET меня удовлетворял всем. В самых больших проектах я находил решения самых сложных задач. И вот, через 6 лет мне просто захотелось посмотреть, а что же есть другого на рынке? Естественно, первым делом я наткнулся на RoR.

Качество программного продукта не в последнюю очередь зависит от актуальной документации и тщательного тестирования. Хотелось бы осветить вопрос разработки и тестирования ПО вообще и с использованием среды FitNesse в частности.

Если сделать так:

<?php $this->headScript()->appendFile('/js/my1.js');?>
<?php $this->headScript()->appendFile('/js/my2.js');?>
<?php $this->headScript()->captureStart() ?>
  var action = '<?php echo $this->baseUrl ?>';
<?php $this->headScript()->captureEnd() ?>

<?php echo $this->headScript(); ?>
<?php echo $this->magicHeadScript(); ?>

то вместо чего-то типа такого:

<script type="text/javascript" src="/js/my1.js"></script>
<script type="text/javascript" src="/js/my2.js"></script>
<script type="text/javascript">
  var action = '/123';
</script>

получим на выходе:

<script type="text/javascript" src="/cache/js/1b1004a203..._compressed.js"></script>


Фрилансеры часто рекомендуют своим клиентам оплатить работу через терминалы.

Это удобно для клиентов далеко не всегда знающих, что такое электронные деньги, но пользующихся терминалами для оплаты повседневных услуг. Да и для оплаты нужно всего 2 шага:

• Записать номер кошелька, обычно, Яндекс.Деньги или Вебмани
• В терминале ввести номер кошелька и вставить оговоренную сумму в купюроприемник.

Все просто, но возникает несколько неудобств при оплате в терминалах:

• Фрилансер не может определить, что работа оплачена, так как платежи приходят без комментариев (заказчику приходится дергать ТП, чтобы узнать номер транзакции). Это особенно актуально, если у фрилансера много заказчиков и платежей.
• В терминалах есть комиссия и фрилансер рискует получить на свой кошелек меньшую сумму, а клиенту приходится бежать к терминалу еще раз, чтобы доложить 10-50 рублей. Даже не смотря на наличие в некоторых терминалах калькулятора комиссий.

Процесс оплаты можно сделать еще проще, принимая оплату через терминалы следующим образом:

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

Amy Editor

Созданый в 2007 Петром Кронторадом (Petr Krontorad), Amy Editor продвинутый редактор с интерфейсом в стиле Mac. Amy Editor имеет в наличие кучу полезных опций, такие как нумерация строк, подсветка синтаксиса, сниппеты для более чем 20 языков, совместное использование и прочее.

» http://www.amyeditor.com

Добрый день смотрим сразу как это работает:



Zen Coding
chikuyonok — Сергей Чикуёнок
pepelsbey — Вадим Макеев

Этот способ ускоренного написания HTML и CSS кода разрабатывается Сергеем Чикуёнком, который «знает толк в извращениях».

HTML код пишется на CSS манеру:
div#content>h1+p

Нажимаем нехитрое комбо на клавиатуре (Ctrl+,) и получаем результат:
<div id="content">
    <h1></h1>
    <p></p>
</div>

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

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

Привет!

Представляем хабрасообществу новый сервис от онлайн-бухгалтерии "Мое дело".

Теперь все документы, необходимые для регистрации ИП, можно подготовить за 10 минут на условиях DonationWare. То есть абсолютно бесплатно, но если если все очень понравилось, то можно сказать спасибо.

Подробности и скриншоты под катом.

Наткнулся вчера на этот инструмент и не смог пройти мимо, провел ночь за написанием тестов, а теперь хочу поделиться находкой. QUnit — это библиотека от разработчиков jQuery, позволяющая писать unit-тесты для кода на javascript. Удобна в использовании, ничего лишнего, осваивается за 20 минут, выгода от применения — колоссальная.

Самым нетерпеливым сразу ссылки:
Официальная документация на сайте jquery: docs.jquery.com/QUnit
Реальные примеры тестов (для модулей jquery): view.jquery.com/trunk/jquery/test/unit
Руководство для начинающих (англ): www.swift-lizard.com/2009/11/24/test-driven-development-with-jquery-qunit
Система распределенного тестирования (гениально и просто): testswarm.com

Под катом информация о преимуществах юнит-тестирования применительно к js и разбор возможностей библиотеки на примерах.

Проблема — нужно обновлять сайт (ака «svn up») плюс обновить схему БД — добавить таблицы, индексы и т.п.
SQL запросы на обновление БД хранятся в репозитории, необходимо запустить нужный SQL после обновления кода приложения.

Сложность: 1) нельзя, чтобы один и тот же SQL выполнился два раза. 2) выполнять запросы нужно в определенной последовательности (нельзя сделать ALTER TABLE до создания).

Это статья о работе фрилансеров. Сам я много раз выступал как в роли заказчика, так и в роли исполнителя работ; наш аккаунт на free-lance.ru занимает 5 место в рубрике "сайты под ключ", хотя ему всего 9 месяцев (пока писал, сместился на 6-ое место).
Хочу поделиться с вами некоторыми соображениями об успешном фрилансе.

1. Правильное взаимодействие с заказчиком – половина успеха.

Грамотное общение с заказчиком – это половина успеха проекта. Помните, недостаточно быть хорошим программистом или дизайнером, чтобы быть успешным фрилансером. Вы еще и менеджер. Много зависит от того, как вы сумеете продать свои услуги, как будете общаться с заказчиком в процессе выполнения работы.
Заказчика в основном интересуют три вещи: адекватность исполнителя, его опыт (портфолио) и цена. Чуть менее – сроки работ.
Показать то, что вы вполне адекватный человек, с которым можно работать – это самое легкое из этого списка. О некоторых простых вещах при общении многие фрилансеры забывают. Не выставляйте заказчика дураком, даже если он действительно совершенно не разбирается в вопросе. Не дайте почувствовать ему себя ламером. Объясните ему суть вопроса без использования узкопрофессиональных терминов, посоветуйте лучший вариант реализации. При общении не используйте сленг, обращайтесь к заказчику на «вы», пишите без грамматических ошибок. Особенно актуально, когда вы говорите с потенциальным клиентом — вы ничего о нем не знаете. Может он старше вас в два раза и обращение «привет» его коробит.

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

Каждый заказчик хочет заплатить поменьше, получить побольше. Это нормальное желание каждого клиента и покупателя. Но все имеет свою стоимость. И не каждый это понимает, пытаясь сильно сбить цену. Держите свою планку. Можно сделать небольшую скидку, но если заказчик хочет сбросить цену вдвое – значит, это просто не ваш клиент. Цените свой труд. У заказчика может быть масса надуманных причин, с помощью которых он станет просить изменить цену. Самые популярные:
Сейчас я у меня только эти деньги на проект, но в будущем у меня будет много денежных заказов для вас. Когда-нибудь, может быть. Это не повод снижать цену.
Давайте вы поработаете за % от прибыли будущего проекта. А заказчик тогда вообще зачем нужен?
Мой начальник выделил определенный бюджет, я бы рад заплатить больше, но не могу. Практически любой бюджет можно пересмотреть. Нет? Но тогда это проблема заказчика.
А у Васи Пупкина дешевле. Что же вы тогда не заказываете у него?

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

При разработке интерфейсов всегда надо опираться на то, что чем больше возможностей даёшь пользователю, тем более неправильно он их использует. Целые тома рукописей известных и не очень писателей, написанные без использования красных букв на зелёном фоне, жирных выделений и подчёркиваний с перечёркиваниями, остаются великими произведениями. Наша задача, если и не пробудить в пользователе второго Александра Сергеевича, то, как минимум, помочь ему легко, гибко и удобно написать красивую статью, но при этом полностью исключить возможность её испортить. Это не ограничение свободы, это лишь свод законов, которые мы не даём нарушить. Это правила, по которым, в конечном счёте, живёт общество. И любая социальная сеть, по своей сути, является своеобразным государством со своими гражданами (пользователями) и чиновниками (администраторами ресурса). Но, это уже совсем другая история, вернёмся к нашей теме…

В качестве распределенного хостинга возьмем классический пример — создание блогосервиса на основе mu-Wordpress.
Задача — при ограниченном бюджете собрать отказоустойчивую (насколько это возможно) геораспределенную систему. Соответственно все оборудование берется в аредну в различных Дата-Центрах.
И тут следует сказать что не все Дата-Центры одинаково полезны. Высококачественные сдают сервер за 800$, а у низкокачественных вполне можно взять примерно такой же сервер в аренду уже за 100$. И именно эти особенности надо учитывать при создании геокластера.

Теперь о небольших хаках. По умолчанию в mu-Wordpress функция отдачи загружаемого контента сделана крайне неудачно — через PHP. Соответственно она была заменена на загрузку отдельным сервисом и вставкой загружаемого контента прямой ссылкой на статику.
Вторым хаком была модификация контроля кеширования. Кроме указаний кешировать статичные элементы дизайна был введен еще такой хак, который запрещал кешировать запись на время ее обсуждения (по умолчанию — 14 дней), а уже после она отдавалась с заголовком разрешающим кеширование. Кроме того хитро кешировались фиды RSS.
Финальным хаком стала система синхронизации БД — каждый INSERT/DELETE/UPDATE выполнялся на «соседе». Получился такой себе софт-рейд в контексте MySQL+PHP.

С момента публикации первого топика о создании хабраподобной статистики (которую, кстати, почему-то тут не обновляют) с импортированием данных из Google Analytics прошел ровно год.



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

Я давно ждал этого момента, нет честно, где-то в подкорке я очень-очень хотел такой штуки чтобы было удобно писать на CSS без переписывания похожих стилей по два раза, без выыскивания нужных разделов в собственном коде, в общем хотелось чтобы на CSS можно было работать легко и просто, что-то я затянул…И так встречайте xCSS — php-класс для работы с динамическим CSS.

Серия постов про “Web, кэширование и memcached” продолжается. Начало здесь: 1, 2, 3 и 4.
В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached, а также о проблеме одновременного перестроения кэшей.

Сегодня мы поговорим о тэгировании кэшей и о возможности сброса сразу группы кэшей в memcached.



Последний, шестой пост, будет посвящен различным техническим вопросам работы с memcached: анализу статистике, отладке и т.п.

В IT индустрии все чаще встречаются проекты с распределенными командами. Это удобно — спецификация, код, баги, мануалы легко перемещаются из одного конца планеты в другой за доли секунд. Это выгодно — аутсорсинг проектных процессов, будь то разработка, тестирование или саппорт, в Индии или Китае обойдется в 3–5 раз дешевле аналогичных сервисов в странах Европы или США.

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