Google выпустил программные интерфейсы для построения графиков и диаграмм Chart API, которые бесплатны и свободны для использования. Они объединены в едином фреймворке Chart Tools.

С помощью Chart API диаграммы генерируются путём отправки простого URL-запроса на сервер диаграмм Google. Примеры возможных диаграмм можно посмотреть в галерее. Кроме всего прочего, Chart API поддерживает динамические иконки, QR-коды и математические формулы.

Что касается Visualization API (Interactive Chart API), то интерактивные диаграммы создаются через библиотеку JavaScript, разработанную в Google (примеры). В качестве источников данных могут выступать, например, таблицы Google Docs или базы Oracle PL/SQL.

via Google Code Blog

Хотелось бы представить вашему вниманию одну занятную игру, участницу студенческого IGF 2010.

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

Преступление #1: В формах метки не связаны с полями ввода

Использование атрибута «for» позволит пользователям кликать по метке, для выбора соответствующего поля формы. Это особенно важно для чекбоксов и радиокнопок — увеличить область клика.

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

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

«Уверяю вас — пользуясь этой задачкой (и, конечно, еще многими другими) я ещё ни разу серьёзно не ошибся с кандидатом. Ведь формальное знание PHP в кандидате — поверьте, далеко не главное. Значительно важнее — отношение к своему занятию, стремление к развитию, способность играть в команде, видение мира, если угодно. Мне гораздо интереснее, как человек решает задачу, чем её фактическое решение».

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

Microsoft выпустила Fishbowl — opensource клиент для Facebook с богатым функционалом. Fishbowl представлется собой клиентское приложение написанное на WPF, которое дает удобный и быстрый доступ ко всем функциям Facebook. Исходный код распространяется под свободной лицензией MSPL, скачать можно с официальной страницы проекта на Codeplex.

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

Хочу поделиться своим опытом поиска работы и прохождения интервью в Праге. Возможно мой опыт понадобится кому-то здесь, возможно кто-то захочет сравнить, как оно здесь и там. Устраивался я на должность Ведущего Разработчика J2EE. Так что все технические термины будут касаться именно Джавы. Итак, поехали.

Данное руководство создано для тех, кто уже умеет пользоваться Adobe Illustrator, но пока не знает всех тонкостей работы с ним и хочет познакомиться поближе.

Товарищ CurlyBrace уже сверстал представленный здесь макет, спасибо ему!

Для начала посмотрите на то, что мы будем стараться сделать:

После обсуждения рентабельности выпуска бумажной книги я решил все же сконцентрироваться на электронной версии. Если она окажется достаточно популярна, там можно будет и о hard-copy подумать.

В эпоху Web2.0 технологий и взглядов было бы глупо писать книгу в отрыве от ее читателей, поэтому в данном топике выложено предварительное оглавление (чтобы скорректировать дальнейшую работу). Оно преследует две цели: во-первых, дать общее понятие о необходимости клиентской оптимизации. Во-вторых, рассказать о существующих подходах и наиболее современных решениях. Книга не стремится научить оптимизировать сложные JavaScript-приложения или настраивать nginx + FastCGI. Только общий подход и основные методики.

Любые комментарии приветствуются.

Smashing Magazine совместно с дизайн-студией DryIcons предлагают для скачки бесплатный набор иконок Practika:

Давайте опишем типы знаний и как они развиваются в мозгу программиста. Существуют три типа знаний:

• Концептуальные (почему?, что?, если? — т.е. семантика) — понимание концепций, принципов, отношений и основных подходов к разработке программных систем. Этот тип знаний обосновывает почему архитектура приложения или алгоритм должны быть написаны определённым образом, каковы альтернативы и почему выбранный вариант — лучший с логической точки зрения. Концептуальные знания дают широкое видение и понимание того, что стоит за решение конкретных проблем в данной задаче.
  Применение: находите более качественные решения для сложных проблем
  Приобретение: изучение компьютерных и околокомпьютерных наук, концепций проектирования и программирования; создание своих собственных теорий, основанных на практике и опыте.
• Практические (как? — т.е. процедура) — знание того, как решать конкретную проблему в программировании. Это не требует глубокого понимания концепций и теории, стоящих за выбором конкретного способа воплощения.
  Применение: быстрое решение проблем с помощью хорошо себя зарекомендовавших и проверенных решение без изобретения «велосипедов» с нуля.
  Приобретение: поиск существующих решений, обучение на примерах или переиспользование своих решений.
  
• Опытные (включая интуицию) — внутреннее индивидуальное знание, которое формируется со временем в процессе разработки. Этот тип знаний позволяет синтезировать и органично использовать два предыдущих типа знаний, принимая оптимальные решения, а также оценивая получаемые концептуальные и практические знания. Его сложно передать другому человеку, так как немалая его часть находится на уровне подсознания.
  Применение: используйте свой опыт и интуицию для принятия лучших решений.
  Приобретение: разрабатывайте программы и делайте выводы из результатов
  

Вечная проблема при публикации своего email, конечно же не хочется получать в итоге спам на свой ящик, и тут мы начинаем прибегать к различным способам обфускации (чтоб было понятно людям, но не понятно ботам) нашего email адреса.Silvan Mühlemann занялся этим вопросом, создал 9 разных email ящиков, защитил их 9 способами, разместил их на популярном сервере, чтоб их хорошенько проиндексил google, подождал (всего, ничего) 1.5 года и вот он результат...

Работать я начал на II курсе университета. Откровенно говоря, назвать работой, с нынешней позиции, язык не повернётся, но не смотря на это именно там я заработал первую зп. Творили мы, так сказать, виртуальные миры. Демиургов из нас не получилось, поэтому после III курса было принято решение искать нормальную работу программистом. Тогда-то я и узнал впервые что такое собеседование при приёме на работу. В начале не имея опыта было допущено множество ошибок, но не смотря на это были разные компании и разные результаты. Мнения о моём уровне различались порой весьма кардинально: от довольно крепкий середнячок, до никчёмный ни черта не знающий, с амбициями и, о ужас(!), огромными запросами по зп. С тех пор утекло много воды, ту планку за которую мне говорили я никогда не прыгну я давно перешагнул.
Сейчас я хочу поделиться своими знаниями о собеседованиях, накопленными за время моих поисков.

Добрый день!

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

Данная статья является продолжением статьи Загрузка классов в Java. Теория.

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

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

В этом топике я хочу описать некоторые базовые различия между примитивными типами и соответствующими им объектными на примере int и Integer. Различия эти достаточно простые и, если немного задуматься, то вполне логичные, но, как показал опыт, программист не всегда над этим задумывается.

Основное различие, разумеется, в том, что Integer — это полнофункциональный объект, который занимает место в куче, а в коде вы пользуетесь ссылками на него, которые неявно преобразуются в значения:

int a = 1000; // a - число
Integer b = 1000; // b - ссылка на объект

При присваивании значения переменной типа Integer обычно выделяется память в куче под новый объект, как будто вы написали new Integer(1000) (так называемый autoboxing). Однако иногда переиспользуются старые объекты. Это иллюстрирует следующий код (JDK 1.6):

Integer a1 = 50;
Integer a2 = 50;
Integer b1 = 500;
Integer b2 = 500;
System.out.println(a1==a2);
System.out.println(b1==b2);

Результатом выполнения будет:

true
false

Мемоизация — (Memoization, англ) вариант кеширования, заключающийся в том, что для функции создаётся таблица результатов, и будучи вычисленной при определённых значениях параметров результат заносится в эту таблицу. В дальнейшем результат берётся из данной таблицы.
Эта техника позволяет засчёт использования дополнительной памяти ускорить работу программы.Данный подход очень частно применяется в функциональных языках программирования, однако и в императивных ему так же можно найти применение. В данном топике рассматривается использование мемоизации в языке java приводятся различные примеры мемоизации и в конце производится небольшое сравнение производительности данных методов.

Зачем мы это сделали?

Многим известно, что практики Agile/Scrum просты на бумаге. Каждый, кто читал про Agile, может расказать все принципы и практики всего за каких-то полторы минуты (а то и меньше). Однако, не смотря на простые правила организации Agile-процесса, нередко допускают большое количество ошибок. Это приводит к тому, что у вас получается ScrumButt.

Поэтому мы решили написать чеклист по Agile-процессу, основанный на нашем опыте. Он поможет разобраться с базовыми вещами и не наступить на типичные «Грабли» совершаемые большинством команд.

Во многих проектах требуется посчитать время, которое затратил тот или иной метод. Для этого можно вручную сохранять значение System.currentTimeMillis() и после метода вычислять затраченное время. Когда методов много это становится не очень удобным.
Поэтому я решил написать простенькую аннотацию, которая бы считала время выполнения метода. Попытавшись найти информацию в интернете, понял, что её по данной теме очень мало. Придётся как-то выкручиваться, собирая информацию по крупицам.

(прим. перев. Перевод немного вольный, но я попытался максимально точно сохранить смысл текста, в то же время отыгравшись на некоторых некритичных моментах, просьба не судить строго :)
Должен также отметить, что я не по всем пунктам согласен с автором (в конце он уже начинает зарываться) и, разумеется, обзоры кода — это не серебряная пуля, но, тем не менее, очень и очень полезная практика.)

Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.

Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.