Легально, бесплатно, без смс.

Проверено и работает на последней версии 3.4.2 (win)

Хочу внести свой скромный вклад в тему DIY компьютерных столов. Весь последний год я активно мониторил рынок в поисках подходящего моим требованиям — и не нашел. Выход один — сделать свой. Далее рассказ о компьютерном столе моей мечты.

Самая частая из проблем, с которыми я встречаюсь в проектах, — что менять в первую очередь, на чём фокусироваться. «Как» все знают или считают что знают. У меня припасено несколько хаков, которые позволяют за полдня провести первичный анализ, выявляющий точки фокуса.



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

(пятница)

Обычно развернутое приложение в файловой системе выглядит как-то так:



Совершенно незащищенное от инструментов типа рефлектора или IlSpy, но что если оно станет таким:



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

3 августа в сабреддите /r/Anarchism некто пользователь PhineasFisher создал тред, в котором сообщил о том, что ему удалось украсть 40 гигабайт различных данных компании Gamma International. Возможно, подобная история могла оказаться не столь громкой, если бы не бизнес, которым занимается эта европейская фирма — создание и продажа программных средств для взлома и скрытой слежки (а иными словами — самой настоящей малвари), заказчиками которых обычно выступали государственные структуры. Через несколько дней после первого сообщения взломщик выложил длинный рассказ о том, как ему удалось проникнуть на сервера Gamma International и что удалось там найти.

IT-интерфейсы часто растут из физических. Например, вот аппаратные чекбоксы:



Вообще, лучший же пример правильного инженерного интерфейса – это гранёный стакан.

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

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

BaasCMS — это JavaScript CMS, использующая в качестве бэкенда популярных провайдеров BaaS. На данный момент поддерживается только Parse.com.

Исходный код BaasCMS доступен на GitHub.

BaasCMS Demo на GitHub Pages
Тоже самое BaasCMS Demo на Tumblr

Можно посмотреть Админ-панель для этого демо (изменения/добавление запрещены). В соответвующую форму на главной странице админки нужно вставить следующие ключи:

• Application ID: nM7P7NnFA95CK1WrqWOf9wa3mskctaTOdk9vYflj
• Javascript Key: 0zHfA9FG8L1xR699qmFXjxkZ1pDxgml0MWZMpqJG

* Надеюсь, ilusha_sergeevich не обвинит меня в плагиате.
Если что, пост переименую.

[Тут была картинка для привлечения внимания]

• donut.js — микро-библиотека, рисующая бубликовые (donut chart) и круговые диаграммы
• Балалайка
• Функция procrastinate
• Противный зловред
• Идея: mousedown вместо click
• Совет: меньше используйте CDN
• Редактор SuitUp и чистка WYSIWYG от мусора
• Простейший полифил для addEventListener
• Репорт об опечатках на сайте
• vanillatree — ванильная замена jstree
• Немного опросов

Всем привет! За время работы постепенно накапливаются наработки, которыми можно было бы поделиться с сообществом. Но ни одна из этих наработок не тянет на большой полноценный пост. Поэтому я собрал все мелочи, что вспомнил, в одной статье: несколько простых опен-сорц проектов, пара советов и находок. Каждый из предложенных скриптов в этой статье поставляется как есть, под лицензией WTFPL (кроме Балалайки). С радостью приму пулл реквесты с исправлением багов или изменениями в README.

donut.js — микро-библиотека, рисующая бубликовые (donut) и круговые диаграммы

Во время работы над очередным проектом, появилась задача нарисовать много информативных бубликов на карте мира, и не просто нарисовать, а еще и поддержать ИЕ8, который, как известно, не умет SVG, а только безобразный VML. Первое, что приходит в голову, это Raphael. Порывшись некоторое время, я нашел это решение. К сожалению, автор проявил изобретательность простым хаком: на круговой диаграмме (pie chart) он нарисовал белый круг. Это решение не подошло, так как дырка бублика должна быть прозрачной. Изучение возможности рисования при помощи Raphael таких диаграмм мне показалось чересчур трудоёмким. Остальные скрипты на просторах интернета мне так же не подошли. Пришлось писать свой костыль, взяв за основу математику рисования арок этого проекта. Арки для VML версии нарисованы используя элемент arc.

var myDonutDiv = donut(options);

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

Вот исходный вопрос:

Как используется ключевое слово yield в Python? Что оно делает?

Например, я пытаюсь понять этот код (**):

def _get_child_candidates(self, distance, min_dist, max_dist):
    if self._leftchild and distance - max_dist < self._median:
        yield self._leftchild
    if self._rightchild and distance + max_dist >= self._median:
        yield self._rightchild

Вызывается он так:

result, candidates = list(), [self]
while candidates:
    node = candidates.pop()
    distance = node._get_dist(obj)
    if distance <= max_dist and distance >= min_dist:
        result.extend(node._values)
        candidates.extend(node._get_child_candidates(distance, min_dist, max_dist))
        return result

Что происходит при вызове метода _get_child_candidates? Возвращается список, какой-то элемент? Вызывается ли он снова? Когда последующие вызовы прекращаются?

** Код принадлежит Jochen Schulz (jrschulz), который написал отличную Python-библиотеку для метрических пространств. Вот ссылка на исходники: http://well-adjusted.de/~jrschulz/mspace/

Всем известно, что 90% информации мы воспринимаем визуально, в краткосрочной памяти может одновременно храниться от 5 до 9 объектов, а эпоха Twitter установила для текстов болевой порог в 140 знаков. Удержание внимания игроков (как и самих игроков) актуально даже для китов игровой индустрии, что уж говорить про небольшие компании, в которых от решения этой проблемы зависит жизнеспособность их проекта.

Настраивать VDS'ки для выкладки django-проектов довольно утомительно бывает, да и легко что-то забыть (т.к. делаешь это не каждый день). Гораздо лучше, когда этот процесс автоматизирован: с меньшими усилиями можно получить правильно настроенный проект и набор команд для работы с ним.

Существую разные подходы к этому процессу: специфичные для питона (fabric, buildout) или неспецифичные (puppet, Chef, наборы shell-скриптов и т.д.).

Подход fabric — локально выполняемый скрипт ходит по ssh на сервер и выполняет там команды. Этот подход довольно прямолинеен и прост в отладке, тем и хорош (обзор на хабре). Из разнообразных команд fabric постепенно вырисовался велосипед под названием django-fab-deploy. Это набор fabric-скриптов, который умеет настраивать серверы под Debian Lenny или Squeeze, а потом с минимальными усилиями разворачивать там django-проекты и управлять этими проектами в дальнейшем.

С выходом Debian Squeeze взялся за django-fab-deploy посерьезнее, поправил некоторые шероховатости и теперь, думаю, самое время об этом проекте рассказать. У проекта есть документация, тут будет краткий пересказ с лирическими отступлениями.

Недавно мне пришлось поработать с библиотекой Google Gson, предназначенной для преобразования Java-объектов в текстовый формат JSON (сериализация) и обратного преобразования (десереализация). Часто при работе с Gson хватает стандартных настроек библиотеки, но бывают случаи (в том числе мой), когда необходимо кастомизировать процессы преобразований.

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

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

Привет, читатель хабра.

Наверное, ты сразу спросишь меня: «Да кто ты такой, чтобы давать мне советы?». Итак, немного обо мне.

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

Я не хочу рассказывать как надо делать, эта статья результат моего опыта и попытка написать рекомендации тем, кто только начинает, хотя и для матерых верстальщиков (слово режущие слух) здесь могут найтись интересные идеи.
Если ты заинтересовался прошу под кат…

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

Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

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

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.

По роду своей деятельности я нередко становлюсь свидетелем «священных войн» между коллегами-программистами на тему, какую же систему контроля версий выбрать для того или иного проекта. Роль системы контроля версий особо остро ощущается в случаях разработки и поддержки проектов с длинной историей. Вариантов инструментов много, но я хочу сконцентрироваться на двух, на мой взгляд, наиболее перспективных: Mercurial и Git. Далее попробуем рассмотреть возможности обеих систем с позиции их внутреннего устройства.

Года два назад я обнаружил, что в Android Market нет удобных мне приложений для учета времени, затраченного на разные проекты. Как настоящий лентяй, я решил не искать требуемое, а написать его сам. Это оказалось несколько сложнее, чем казалось вначале, и я все забросил в режиме вялотекущего хобби воплощение моего желания прожило больше года, медленно продвигаясь от идеи к альфа-версии.

И тут вдруг добрые люди предложили мне рассказать, как писать под Android на Kotlin'e. Мне показалось, что это добрый знак, и я быстро переписал приложение на Kotlin, закончил его и выложил в Google Play.

Важное уточнение: эта статья — только про то, как писать под Android на Kotlin'e. Интересно будет только тем, кто хочет попробовать Kotlin, и тем, кто хочет понять, зачем его пробовать. Приложение, которое я написал — очень-очень простое (и само по себе никак не относится к JetBrains). В его коде гарантированно можно что-то улучшить, оно выложено на Github только для примера, а не в качестве образца восхитительного кода. Оно работает, и если вам хочется его попробовать, то поставить можно отсюда. Но еще раз: это — демо, его цель — быть не совершенным приложением, а введением в Kotlin под Андроид.

Опять что-то новое. И зачем мне это знать?

Свой собственный сленг рано или поздно образуется в любой команде. Айтишный же, наверное, складывается на 90% из словечек, которые более-менее понятны любой другой компании-разработчику, особенно в контексте. А на 10% — из особенностей фунциональности разрабатываемого продукта или конкретного разработчика.
Под катом – профессиональный словарик девелоперов Parallels. А какие у вас в команде крылатые выражения?

Впервые слышите о tornado? Слышали, но боялись асинхронности? Смотрели на него более полугода назад? Тогда я посвящаю эту статью вам.

Так получилось, что несколько месяцев я пытался серьёзно использовать в качестве сервера, железку на ARM процессоре.
Об этом я писал тут и тут.
Производительности мне часто не хватало, и я находил и искал различные альтернативы, часто активно использующие C/C++. Парочка библиотек под катом.