Это руководство подскажет вам, как буквально за 10 минут создать простой, удобный и надежный аналог Dropbox, который будет под вашим полным контролем и позволит обмениваться файлами с коллегами по локальной сети.

Всем привет! По многочисленным просьбам наших пользователей и читателей выкладываем статистические данные по использованию баз данных, серверов приложений, а также версий Java и PHP в облаке Jelastic. Данные собирались довольно простым образом: мы просто подсчитали количество наших пользователей, которые использовали тот или иной программный стек при создании окружений на платформе Jelastic за прошлый месяц (все тестовые аккаунты, конечно же, исключили). Также в данной статье можно отследить тренды за последний год для баз данных и всего, что касается Java, и за последние 5 месяцев для серверов приложений и версий PHP (так как поддержка PHP была реализована в конце января этого года).

Базы данных

Как видим, победитель среди баз данных вполне предсказуем – это MySQL (65%). С большим отрывом второе место занимает «сестра» MySQL – MariaDB, которую используют 12% наших пользователей. Тройку лидеров замыкают Postgres и Mongo – по 11% у каждой. Ну, и аутсайдер, нашего состязания — CouchDB, которая набрала всего один процент.

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

Все компании разные, но между лучшими техническими руководителями, с которыми мне довелось работать, существует кое-что общее. Снимаю шляпу перед Брайаном Столером, Натаном Хантом, Эваном Гилбертом и Ричем Бердоном за то, что послужили мне хорошим примером.

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

Качества

Вы всегда должны улучшать три своих качества: компетентность, скорость и осведомленность.

Добрый день, дорогие Хабравчане!

В качестве дебютного поста мы решили предоставить вам подборку фактов и мифов об облачных технологиях. Специально для этого мы перевели и адаптировали инфографику, созданную в DeVry University (США). Надеемся, что вы найдете в ней для себя что-то новое, полезное и интересное. Итак, начнем:

Картинка для привлечения внимания, clckwrks — веб-фреймворк, тесно связанный с Happstack.

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

На этой неделе мы выкладывали первую часть расшифрованного подкаста. Сейчас подготовили вторую часть.

О чем мы говорим во второй части подкаста:

• Горизонтальное масштабирование проекта

— когда стоит использовать облачные сервисы, а когда физический хостинг;
— «красивость решения» против «грязного, но производительного» кода. ORM и всякие подобные штуки;
— мультиязычность и мультизонность проекта, проблемы и решения.

• Асинхронные задачи. Очереди.

— асинхронные задачи в распределенных системах;
— когда они приходят на помощь, какие технологии существуют и активно развиваются сейчас;
— какие подходы организации асинхронных задач используются в Badoo;
— c какими проблемами приходилось и приходится сталкиваться при работе с очередями;
— полезные книги и интересные конференции;
— интересные кейсы с собеседований.

Возможно вы помните пост: Нужна ли книга по Hadoop?, в котором мы хотели узнать ваше мнение, стоит ли издавать эту книгу на русском языке. Прошли положенные 9 месяцев, и мы готовы представить её вашему вниманию.

Встречайте:

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



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

По-моему, эта статья — самое важное, что я в жизни сделал. Не самое сложное, объёмное или интересное, а важное.

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

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

Откроем Википедию и посмотри что пишут про форматы .DXF и .DWG и развитие их.

DXF — открытый формат файлов для обмена графической информацией между приложениями САПР. Был впервые представлен в декабре 1982 года как часть AutoCAD 1.0, в качестве обменного формата данных, предоставляющего ту же информацию, что и закрытый внутренний формат AutoCAD — DWG, спецификация на который никогда не предоставлялась.

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

Это шаблон описания сути вашей компании или проекта в одном предложении. Я открыл его для себя во время стажировки в США. Составив его, мы реально становимся сильнее. В последствии мне это помогло выбрать правильный курс, сфокусироваться и расставить приоритеты.

Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

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

Об использовании JavaScript-фреймворка Backbone.js написано много, но просто и кратко — мало. Я постараюсь исправить этот недостаток и рассказать разработчикам web-приложений максимально просто, доступно и кратко о том, зачем им может пригодится этот фреймворк и как, в общих чертах, он работает. Профессионалы и специалисты по Backbone.js: можете не тратить время, этот рассказ для новичков. Если быть честным, то для чтения этой заметки не обязательно быть Rails-developer'ом, надеюсь, статья пригодится всем, кто работает с любым из МVC-фреймворком.

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



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

Недавно я перешел с knockout.js на angular.js, оба инструмента мне нравятся, но в каждом из них есть свои преимущества перед «конкурентом».
И тут выпал скучный вечер, решил я, just for fun, слепить свой MV* инструмент.

Мне не очень нравятся разухабистые фреймворки, я отдаю предпочтение библиотекам, и от angular мне в основном нужно было 2 вещи: scope — данные и их мониторинг, applyBindings — привязать этот scope к DOM.

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

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

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

Первым движком, интерпретирующим js-код стал SpiderMonkey, который был представлен в браузере Netscape 2.0 в 1995 г. Миф о его быстром создании хорошо задокументирован. У Брендана Айка было всего 10 дней на дизайн языка и построение компилятора. Javascript был успешен с самого начала, и к августу того же кода Майкрософт уже встроила свою версию JScript в Internet Explorer 3.0. К концу 1996 язык был принят в комиссию для формальной стандартизации, и уже в июне следующего года обрел официальный стандарт ECMA-262. С тех пор поддержка JS стала обязательно для каждого браузера, и каждый крупный производитель начал строить свой движок для поддержки JS. В течение долгих лет эти движки развивались, заменяли друг друга, переименовывались, и становились основой для следующих движков. Отследить все созданные версии — задача не для слабых духом.

С вами новый выпуск познавательных интервью и репортажей из Кремниевой Долины. На этот раз интервью не с Rock Star, от которых уже наверное немного устали, а просто с талантливым предпринимателем из Долины, сумевшим недавно построить успешно развивающийся бизнес и собрать команду из 8 человек. Илья Сёмин, бывший разработчик Nokia, однажды решил бросить работу в компании и переехать через всю Америку из Бостона в Кремниевую Долину, чтобы построить свою компанию там. Илья создал приложение, которое по принципу поисковика обходит миллионы сайтов и смотрит, какие интернет-технологии на них искользуются. На основе этой информации клиенты могут, например, увидеть, когда продукт конкурента появился на одном из сайтов, и, воспользовавшись моментом, «перехватить» клиента у конкурента.

Например, если компания делает продвинутую версию Google Analytics, то Datanyze поможет ей отследить тех, кто использует данную технологию и, таким образом, даст список потенциальных клиентов, которым можно сервис предложить. Как говорит сам Илья: «Datanyze — это инструмент для того, чтобы в нужный момент в нужную компанию предложить свой продукт. Мы даем информацию о том, кому предложить, когда, их контакты и всю необходимую информацию о компании (сколько человек работает, какая у них прибыль, фандинг, год основания и т.д.).» В интервью Илья Сёмин рассказывает, почему он бросил работу в Nokia, как он создал компанию, почему не ищет инвестиций, а также поделится секретами маркетинга в Twitter и LinkedIn. Под катом больше информации и вопросы интервью.

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

Но если не можете забыть о работе даже за шашлыком, то вам поможет только транс. Транс — это самый эффективный и глубокий отдых. Качественнее отдохнуть просто невозможно :)

Часть 1: Введение
Часть 2: Многопоточность
Часть 3: Рендеринг (Прим. пер. — в процессе перевода)
Часть 4: Doom classic — интеграция (Прим. пер. — в процессе перевода)

Движок для Doom III был написан в период с 2000 по 2004 год, в то время, когда большинство ПК были однопроцессорными. Хотя архитектура движка idTech4 разрабатывалась с учетом поддержки SMP, это закончилось тем, что поддержка многопоточности делалась в последнюю минуту (см. интревью с Джоном Кармаком).