← All posts tagged dev

Kxepal
Kxepal
dev pycon Просматривая доклады про тестирование на UA.PyCon вспомнил другой, старый, но прекрасный доклад Павла Кудинова "Костыли — это кошерно!"
vimeo.com
и в очередной раз выполз из под стола(:
Kxepal
Kxepal
web dev JSON Вышла новая версия спеки про JSON Patch:
tools.ietf.org
Много хороших уточнений, но на этот раз они "взяли и все сломали": сделали список ключей фиксированным, что в общем-то и правильно, но стало многословней.
Kxepal
Kxepal
dev JS Коротко о новом в еще не стандартизированном EcmaScript 6-ой редакции
espadrine.github.com

Понравились модули; генераторы/итераторы/default args/rest args/array comprehension — здорово их видеть, хотя синтаксис местами неоднозначный, но дело привычки. Ох, они еще ввели class-like syntax! что теперь будет-то...(:
Kxepal
Kxepal
dev Почему объектно-ориентированное программирование провалилось?
blogerator.ru

Не являюсь сторонником какого-либо "лагеря", но статья прекрасна и некоторые мысли очень здравы, например:
Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг...

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

Спасибо @yzh44yzh за ссылку.
Kxepal
Kxepal
dev Python Локальные итоги по запиливанию поддержки сразу python 2.4 — 3.2 в simpleubjson:
1. не смотря на набор -костылей- слоя совместимости простой бенчмарк отностительно python 3.x показал прирост производительности +10% относительно безкостыльной версии только для ветки 2.х;
2. операция .decode('utf-8') очень тормозная для python 2.x;
3. при добавлении разных проверок версий, можно выйти с минимальными потерями производительности — это дешевле холстого вызова функций совместимости;
4. six хорош как прокси, но u() и b() станут первым местом для оптимизаций;
5. городить совместимость всего и вся на уровне библиотеки, работающей только с байтами, при полной юникоидности всего жутко неудобно;
6. в целом, если навести порядок с тем, где у нас ходят байты, а где юникоды, то жить очень даже можно — больше всего времени потратил на приведение тестов в порядок т.к. там с этим делом был полный бардак в отличии от.
Kxepal
Kxepal
dev Python ubjson Определенно, текущая реализация simpleubjson — прекрасный пример того, как не надо писать decoder/encoder для какого-то формата данных. Вроде просто и выглядит ничего, но проблема одна на другой. А посмотришь на исходники simplejson и не подумаешь, что та каша кода на самом деле прекрасное решение множества бед. Придется свое "simple" решение усложнять, но что делать — max recursion depth сам по себе никуда не денется(:
Kxepal
Kxepal
web dev После #1745984 решил погуглить вопрос о версионировании http api и, собственно, большая часть идей сводится к двум ответам на stackoverflow:
stackoverflow.com

1. Версионирование через ветки url. Например: example.com/2.1/foo/bar/baz ; example.com/1.4/gav/gav/gav. В добавок к этому, есть ветка без указания версии example.com/foo/bar/baz, которая должна делать редирект на актуальную версию. Все бы прекрасно, но как-то через-чур избыточно.
2. Версионирование через медиа тип. Например: application/vnd.example.myapp-v3+json. Красиво, но если только у нас свой формат. В случае json большинство средств его обработки ожидает медиа тип application/json, для xml — application/xml. Соответственно мы рискуем получить множество проблем с кодированием/декодированием данных, поскольку вряд ли большинство библиотек проектировалось с с мыслью, что стандартные медиа типы могут измениться внезапно завтра.
3. Версионирование через данные. Например <?xml version="1.0"?><foo version="2.3.4-dev"/>. Вроде данные явно указывают согласно какой версии спецификации их обрабатывать, но такая информация должна быть размещена в заголовках — не зря их называют метаданными — иначе серверу возможно придется прочитать полностью все 500 мегабайт данных просто чтобы понять, что указанная версия более не поддерживается, а следовательно время и ресурсы потрачены зря.

В качестве развития мысли второго варианта можно использовать свой произвольный заголовок, например X-API-VERSION, и его значение обрабатывать согласно, например, тому же semver.org
Мне кажется такой вариант хорошим компромиссом т.к. мы не плодим кучу ресурсов, не заменяем стандартные медиа типы на вендорные,. но в тоже время следуем семантике HTTP протокола и наш заголовок несет атомарную функциональность. Да, тут #1740551 оказывается предлагают X- выкинуть как анархизм, но это тянет на холивар и уже совсем другая история(:
Kxepal
Kxepal
web dev JSON Спека-соглашение по HTTP доступу к JSON ресурсам
tools.ietf.org
После множества статей про REST у меня сложилось стойкое déjà vu, хотя, наверное, имеет право на жизнь.