“Есть ложь большая, есть маленькая, а есть статистика производительности Java.”

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

Многим понятно, что такие тесты это часть маркетинга. И те кто его заказывает, заказывают и результат. Но удивительность ситуации в том, что упрекнуть во лжи некого. Нельзя отказать в истинности тех тестов в которых Java на порядок уступает C#, ни тем тестам в которых Java превосходит С++ (не Си). Проблема в том, что такие тесты ориентированны в основном на начинающих разработчиков с целью переманить в свой стан побольше программистов и тем самым увеличить коммерческую привлекательность платформы для бизнеса. И в таких тестах намеренно упускаются сложные для понимания подробности работы динамической JIT компиляции и адаптивной оптимизации HotSpot, в которые начинающие программисты редко вдаются.

Чем это чревато? Банальным когнитивным диссонансом.

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

Краткое содержание поста:

1. тестирование веб-сайтов — это сложно и непонятно
2. юнит-тесты в django
3. тестовая БД и как с ней бороться
4. smoke testing
5. покрытие кода (code coverage)

Продолжаем неделю задачи Эйнштейна на Хабре. В дополнение к трём представленным решениям

1. Регулярным языком
2. Хаскеллем
3. Прологом

позвольте представить еще одно на Mercury.

Напомним Википедию:

Mercury — язык функционально-логического программирования со строгой типизацией…

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

Это интервью Криса Уонстрота, CEO и сооснователя Github. Данное интервью — часть серии “Bootstrapped, Profitable, & Proud” о компаниях с выручкой более миллиона долларов, обошедшихся без венчурного финансирования на старте и приносящих доход.

У самого ubuntu нету, поэтому попросили разместить. Думаю статья окажется полезной.

Еще в прошлом году на Хабре вышла статья о «релаксирующем» текстовом редакторе Ommwriter. Специфическая визуальная оболочка не могла не привлечь графоманов, нуждающихся в полном погружении в процесс написания текста. К сожалению, на момент выхода статьи хабраюзера langolf (а, впрочем, и до сих пор) не вышло ни одной версии для Linux.

Однако, это не означает, что аналогов Ommwriter не существует. Я был порядочно удивлен, случайно узнав о существовании многих программ, подходящих для такого рода графоманства. Поэтому мною был подготовлен небольшой обзор «focus on writing» текстовых редакторов для Linux.

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

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

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

Этот дайджест основан на моем приличном опыте мониторинга и анализа сайтов на рынке веб-разработок (исследования конкурентов в ADV, мониторинг и анализ участников «Тэглайн», проведение заказных аудитов для студий и пр.).

Я попытался систематизировать основные «ляпы» и упущения по нескольким основным категориям, на которых и остановлюсь подробнее:

• Ошибки позиционирования;
• Ошибки расстановки приоритетов;
• Неправильная презентация компании и услуг;
• Неправильная презентация портфолио и кейсов;
• Ошибки в коммуникации с заказчиком;

Когда мы начинали планировать, как будет устроен сервис Evernote, в 2007 году, мы знали, что в первый же день нам понадобится поддержка как “тонких” (таких как браузеры), так и “толстых” синхронизируемых клиентов. Это побудило нас задуматься над удаленным протоколами и клиентским API еще до начала работы над любым GUI для веба. В противном случае пришлось бы ждать несколько месяцев, пока прикрутят API на уже существующий веб-сервис.

Наши приложения предъявляют к API определенные требования, как то:

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

Случайно наткнулся на свеженаписанную утилиту ioping, написал её русский программист koct9i, пользователь k001 оформил в rpm для fedora 14 . ioping на google code.
А пользователь Grohman собрал ебилд, а LupineDreamer сделал деб-пакет i386 и x64 от magzimko.

Выглядит это дело примерно вот как:
$ ioping -i 0.2 -c 6 -s 1M -S 10M /tmp
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=1 time=0.7 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=2 time=191.3 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=3 time=18.4 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=4 time=12.4 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=5 time=8.4 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=6 time=8.2 ms

За последнюю неделю появилось несколько топиков с названием «10 однострочников на <MY_LANGUAGE>, которые произведут впечатление на ваших друзей», которые содержат однострочное решение нескольких простых задач, демонстрирующее достоинства и «крутость» любимого языка программирования автора. Я решил перевести их и для сравнения собрать в одном топике. Вся волна началась (вроде как) со Scala.
Итак, поехали!

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

В Сети можно обнаружить массу советов, статей и FAQ для web-маcтеров, которые посвящены теме взаимодействия сайтов и поисковых систем. Поэтому принципиально нового в идее schema.org, конечно, нет. На нем собрано (пока довольно небольшое) число примеров рекомендуемой HTML-разметки и некоторой другой полезной информации, использование которой web-мастерами позволит создавать «правильные» сайты, анализ которых поисковыми системами будет наиболее быстрым и эффективным, что, в свою очередь, позволит пользователям быстрее находить интересующую их информацию.

Более любопытным является то, что создателями сайта являются три крупных игрока IT-рынка, для двух из которых область интернет-поиска является, как минимум, ключевой в их бизнесе. Сайт создан Google, Yahoo! и Microsoft и, признаться, не часто приходиться видеть объединение конкурирующих компаний в деле, которое реально может быть полезным для обычных пользователей сети.

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

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

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

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

Цель обзора — упорядочить представления о рынке веб-разработки. Упорядоченные представления о потребностях позволят в дальнейшем выбрать подходящую нишу для своей разработки и определить конкурентные преимущества нового продукта или веб-ресурса. Обзор может быть полезен разработчикам, которые выпускают на рынок новые решения или начинающим веб-студиям, так как в условиях высокой конкуренции необходимо выявить не охваченные потребности заказчиков (или создать такие потребности) и закрепиться на рынке. Точка зрения «Заказчик» обусловлена необходимостью в первую очередь решать задачи заказчика.

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

Объекты, классы, конструкторы

ECMAScript, будучи высоко-абстрактным объектно-ориентированным языком программирования, оперирует объектами. Существуют также и примитивы, но и они, когда требуется, также преобразуются в объекты. Объект — это коллекция свойств, имеющая также связанный с ней объект-прототип. Прототипом является либо также объект, или же значение null.

В JavaScript нет привычных классов, но есть функции-конструкторы, порождающие объекты по определенным алгоритмам (см. Оператор new).

Прототипное делегирующее наследование

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

Теперь представим другую планету, на которой не такое как на Земле генное наследование. Там обитают мутанты с «телепатическим наследованием», которые способны изменять гены своих потомков.
Разберем пример. Отец наследует гены от Дедушки, а Сын наследует гены от Отца, который наследует от Дедушки. Каждый мутант может свободно мутировать, и может менять гены своих потомков. Например у Дедушки был зеленый цвет кожи, Отец цвет унаследовал, Сын тоже унаследовал цвет. И вдруг Дед решил: «надоело мне ходить зеленым — хочу стать сними», смутировал (изменил прототип своего класса) и «телепатически» распространил эту мутацию Отцу и Сыну, вобщем посинели все. Тут Отец подумал: «Дед на старости лет совсем двинулся» и поменял свой цвет в генах обратно на зеленый(изменил прототип своего класса), и распространил «телепатически» свой цвет сыну. Отец и Сын зеленые, Дед синий. Теперь как бы дед ни старался Отец и сын цвет не поменяют, т.к сейчас Отец в своем прототипе прописал цвет, а Сын в первую очередь унаследует от Прототипа Отца. Теперь Сын решает: «Поменяю ка я свой цвет на черный, а моё потомство пусть наследует цвет от Отца» и прописал собственное свойство, которое не влияет на потомство. И так далее.

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

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