Артель BrowserPlus (из Yahoo) выпустила API для сжатия файлов на стороне клиента. Как объясняется в нижеследующем скринкасте, джаваскриптовый API позволяет вам упаковывать и сжимать файлы в клиенте посредством LZMA или tar.


    «Client Side Compression» выложил Lloyd Hilaiel на Vimeo

Вы можете читать далее о реализации или испытать демонстрацию живьём (потребуется BrowserPlus).


    Прилад Browser Plus для упаковки на стороне клиента

Использовать этот API нетрудно: вызываем надобный метод и посылаем ему файлы:

BrowserPlus.Tar.tar({'files':files});
BrowserPlus.LZMA.compress({'files':files});

На GitHub доступны оба эти расширения — LZMA и tar.

Нюансы перевода:  слово «прилад», давно живущее в великорусском языке (как минимум, со времён Даля), здесь служит переводом технического термина «add-on» (а не «device», как в украинском), слово же «артель» означает команду разработчиков (в оригинале — «team»).

Перевод статьи молодого греческого программиста «Why I bill hourly»

Недавно ко мне обратился мой первый потенциальный клиент, который хотел добавить несколько возможностей в небольшое приложение на Django. Я огласил свою часовую ставку, чем крайне его шокировал — он-то хотел услышать фиксированную цену за нужные ему доработки. Что из этого получилось? Мы работаем вместе, он очень доволен как результатами, так и суммами, которые он на них тратит, а я не поступился своими принципами оплаты. Вот аргументы, которые я использовал в защиту мнения о том, почему почасовая ставка лучше для всех заинтересованных сторон — может быть, они помогут кому-то еще.

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

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

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

Стили

User Agent

Один из способов включения стилей для мобильного устройства — это использование User Agent, которую получает сервер от клиента.
Этому может помочь набор скриптов: code.google.com/p/mobileesp, а также сервис от яндекса api.yandex.ru/detector
При работе с User Agent только одна проблема — это постоянно появляющиеся новые User Agent.

В данной статье я хочу рассказать начинающим Java разработчикам, как написать простое веб приложение, используя популярный фреймворк Spring Framework.

При разрабокте приложения мы будем использовать утилиту Ant для автоматизации действий и изучим, как писать простой тест с помощью библиотеки JUnit. Весь код будем писать в Eclipse IDE.

Статья написана на основе первой части руководства «Introduction to Spring MVC». Вам достаточно иметь лишь общее представление о Spring, чтобы прочитать статью с пользой.

Так что милости просим :)

В данной статье речь пойдёт о системе управления содержимым Riot, написанной на Java. Система основана на Spring Framework, использует Ajax.



Я приведу основные возможности системы и пошагово расскажу, как её установить. Статья адресована всем тем, кто интересуется системами управления содержимым на Java.

Иногда возникает необходимость кэширования результатов исполнения методов. Одно из возможных решений для java описано здесь. Всё, в принципе, тривиально: EHCache, Spring AOP для перехвата вызовов, немножко кода.

Рассмотрим, как мне кажется, более элегантное решение на scala.

Когда книгу о бизнесе пишет очередной гуру, консультант или тренер с сомнительным опытом и достижениями, трудно решить как к ней относится. Другое дело прочесть мысли человека за одно поколение ставшего миллиардером, основавшего компанию Virgin в 18 лет (сейчас в нее входит более 200 компаний в 30 странах мира).

Это вторая книга Ричарда Брэнсона, попавшая мне в руки. Первая была «К черту все, берись и делай», она оставила неизгладимый след. Так что сомнений в том, чтобы прочесть и вторую — не было.

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

В последнее время читаю с маркером, выделяя для себя основные, наиболее интересные мысли. Их и предлагаю Вашему вниманию в качестве цитат автора:

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

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

Много слов сказано о том, как правильно писать юнит-тесты, и вообще о пользе TDD. Потом ещё и какое-то BDD замаячило на горизонте. Приходится разбираться, что из них лучше и между ними какая разница. Может, это и есть причина, почему большинство разработчиков решили не заморачиваться и до сих пор не используют ни того, ни другого?

Коротко: BDD — это дальнейшее развитие идей TDD, стало быть, его и надо использовать. А разницу между TDD и BDD я попробую объяснить на простом примере.

Рассмотрим 3 ревизии одного юнит-теста, который я нашёл в одном реальном проекте.

Попытка номер №1

Первая версия этого юнит-теста была такой:

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

Но экономия времени при написании — это ещё не всё. Едва ли не более важным фактором является то, что в многословных описаниях теряется смысл, который туда пытался заложить тест-дизайнер. Поэтому опытному тестировщику работать с короткими описаниями проще, чем с подробными длинными сценариями. И сегодня я хочу представить вашему вниманию перевод небольшой заметки Роба Лэмберта (Rob Lambert), в которой он описывает эксперимент объясняющий этот феномен.

Less Is More, или Меньше слов — больше смысла.

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

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

Если вы пользуетесь твиттером, вы представляете, как это происходит. Иногда приходится немало потрудиться, чтобы суметь выразить свою мысль, используя всего 140 символов, но зато результат получается впечатляющим. Это очень полезная практика, потому что краткость, как известно — сестра таланта.

Большинство моих текстов становятся существенно короче после того, как проходят этап «ужимания», хотя, если постараться, там можно найти ещё немало «ваты».

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

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

* Results-oriented professional (специалист, ориентированный на достижение результата)
* Cross-functional teams (имеется различная специализация)
* More than [x] years of progressively responsible experience (более, чем столько-то лет опыта, в чем-то отмеченного и зафиксированного)
* Superior (or excellent) communication skills (высочайшие способности к коммуникации)
* Strong work ethic (строгое соблюдение трудовой этики)
* Met or exceeded expectations (соответствую или превосхожу ожидания)
* Proven track record of success (есть подтверженный список достижений)
* Works well with all levels of staff (умение хорошо срабатываться с сотрудниками всех уровней)
* Team player (умею работать в команде)
* Bottom-line orientation (ориентирован на результат)

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

Интересно, как обстоит с этим дело в России — у нас же многое перенималось по западным канонам раньше?

Помните тот старый пост, в котором я рассказывал о том, что пишу книгу “Секреты приложений Google”? Права народная мудрость: скоро сказывается только сказка. Тем не менее, в июне этого года, спустя 440 дней после того, как файл “Секреты приложений” появился на моем рабочем столе, книга увидела свет. Мне кажется правильной идея подводить итоги своих проектов и делиться с окружающими тем, что получилось, а что пошло не так, как ожидалось. Компания, в которой я когда-то работал, называла эту практику “Lessons learned”, на Западе такую штуку все чаще зовут “Project post mortem review”, а на русском языке это просто-напросто “Разбор полетов”.

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

Буду краток.
css свойство transform:rotate в ИЕ не доступно.
Но все знают что есть фильтр progid:DXImageTransform.Microsoft.Matrix, который конечно поворачивает изображение. Но скажем так не совсем правильно.
99% статей про использование этого фильтра содержат примерно такую фразу.

filter: матрица трансформации
left:?
right:?
*ps: left и right находятся эмпирически

На самом деле это не так.

Думаю многим верстальщикам известно решение, которое заставляет IE рисовать скругленные уголки: «curved-corner» (или border-radius.htc).

В этой статье я расскажу, как избавиться от ошибок «Invalid argument» при его использовании, а также как в разы ускорить его работу.

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

Проблему можно представить графически так:


Задача вёрстки заключается в следующем:

• — независимо от разрешения (размера она браузера), информативная часть сайта находилась посередине;
• — справа и слева должны остаться графические блоки (уши), причём эти уши должны быть видны только при увеличенном размере экрана браузера, а при уменьшенном не уместившаяся часть должна прятаться (в идеале, чтобы ещё горизонтальной полосы прокрутки не было);;
• — страница должна быть резиновой от 680px до 1000px.

Работает для FF3, FF4, IE8 и почти для Opera.

В догонку к посту про макет бизнес модели, не менее полезный «самый короткий в мире маркетинговый план» (так его назвал автор, Келли Одел).

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

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

А вот рекомендации относительно того, как тестировщики могут оказывать позитивное влияние на менеджеров.

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

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

Хочу выделить следующие важные моменты, касающиеся бизнес плана в целом:
• Бизнес-план – это не только попытка проанализировать ваш бизнес и его шансы, но и ваше руководство к действию в ближайшем будущем после запуска бизнеса.
• Лучший способ писать бизнес-план, особенно на начальных стадиях – с листком бумаги и карандашом. И подальше от раздражителей. И только потом упорядочивание и перенос на компьютер.

Взгляд сверху

Сегодня мы продолжим уже более точечно рассматривать процесс бизнес планирования, но прежде я бы хотел ознакомить вас со списком тем, котрые обычно включаются в бизнес-план, и каждой теме я планирую посвятить по одной статье. Довольно амбициозная задача, так как обычно бизнес-план включает в себя около 15-20 разделов, и каждый важен по-своему. То есть, в идеале у нас с вами должно получиться около 20 статей.

Итак, список:

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель, май-июнь, июль, август.