As such, there’s really no “standard” benchmark that will inform you about the best technology to use for your application. Only your requirements, your data, and your infrastructure can tell you what you need to know.

Для начала немного философии. NoSql окружает и от этого никуда не убежать (хотя не очень то и хотелось). Оставим вопросы о глубинных причинах за рамками данного текста, отметим лишь, что этот тренд отражается не только в появлении новых NoSql решений и развитии старых. Еще одна грань — смешение противоположностей, а именно поддержка хранения schema-less данных в традиционных реляционных базах. В этой серой области на стыке реляционной модели хранения данных и всего остального кроется головокружительное количество возможностей. Но, как и всегда, нужно уметь найти баланс, который подходит именно для ваших данных. Это бывает трудно, в первую очередь из-за того, что приходится сравнивать мало сравнимые вещи, например, производительность NoSql решения с традиционной базой данных. В этой небольшой заметке будет предложена такая попытка и приведено сравнение производительности работы с jsonb в PostgreSQL с json в Mysql и с bson в Mongodb.

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

Введение

Недавно я обнаружил интересную игру под названием VimGolf. Цель этой игры заключается в том, чтобы преобразовать кусок текста из одной формы в другую наименьшим возможным количеством нажатий клавиш. Пока я играл на этом сайте с разными пазлами, мне стало любопытно — а какие привычки редактирования текста есть у меня? Мне захотелось лучше понять способы манипулирования текстом в Vim и проверить, смогу ли я найти неэффективные моменты в моем рабочем процессе. Я провожу огромное количество времени в моем текстовом редакторе, поэтому устранение даже незначительных шероховатостей может привести к значительному увеличению производительности. В этом посте я расскажу о своем анализе и о том, как я уменьшил количество нажатий клавиш при использовании Vim. Я назвал эту игру Vim-крокет.

Отношение между «чистыми» и «прикладными математиками» основаны на доверии и понимании. «Чистые математики» не доверяют «прикладным математикам», а «прикладные математики» не понимают чистых математиков.

Некоторое время назад я столкнулся с тем, что не смог найти доступных материалов, в которых на великом и могучем описывался бы метод погруженной границы. Если в кратце, то это метод вычислительной гидродинамики, который позволяет расчитывать обтекание достаточно сложных по форме и динамике объектов. Так вот русскоязычных публикаций на эту тему было крайне недостаточно. «Не беда, будем читать работы зарубежных коллег» — подумалось мне. Но и тут ждал небольшой подвох — все имеющиеся материалы и публикации по этому методу были очень теоретичны, а мне (не уверен, возможно это не только моя особенность) обычно сложно сделать переход от теоретических выкладок к более-менее рабочему воплощению в коде. Поэтому для таких же несчастных, что и я (и с некоторой долей надежды на советы от умудренных опытом личностей) я решил сделать краткое описание этого метода и предложить самый простой способ его реализации.

Too late — 'cause I got it now
there are monads all around
IO, State and lists abound
It's easy, like those people say
but my program got abstracted all away!
Maybe — o o o,
It's a monad too, I know
Why should I use another language at all?

Снова безумный адепт Haskell, и еще одна попытка доказать его практичность. Нестареющая классика.
Я постараюсь рассказать шикарную историю (не ведитесь на пафосную рекламу), в которой будут все необходимые компоненты блокбастера (я серьезно, не ведитесь) — знакомые герои, хорошо продуманная вселенная и открытая концовка (ну что ж...).

На мой взгляд, самый лучший способ освоить что-нибудь новое в программировании — изучать комиты в публичные репозитории.
Тут вам и предельная практичность, best practices, большое разнообразие и прочее. Есть только один неприятный момент — далеко не каждое изменение в репозиторий можно считать поучительным или хоть сколько нибудь информативным.
Более того, практически никогда нельзя восстановить полный контекст, в котором появилось то или иное изменение — его может знать только сам автор. Можно ли в таких условиях все-таки вытащить крохи полезной информации?

Не буду долго распинаться на тему того, насколько велик и могуч Vim — это уже давно и достоверно известно. Кто-то даже утверждает, что «Практически любая строка латинских букв является синтаксически верной командой для vi».

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

Haskell — пока еще единственный язык программирования, в котором есть оператор «фтопку» (>>=)

Абсурдопедия

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

Один из основных элементов деятельности любого человека, связанного с IT-индустрией, это получение новой информации, ее анализ и применение на практике. Программист постоянно что-либо изучает, он подвержен страстному желанию узнать что-то новое. Сопоставив нынешний уровень доступности информации можно понять (и даже прочувствать) самую трагичную проблему homo programmer — слишком много интересного и слишком мало времени, чтобы в этом разобраться.