От переводчика: Думаю, что статьи по архитектуре приложения и организации кода наиболее важны на начальном этапе, т. к., в отличие от всего остального, основу приложения поменять очень трудно. [Оригинал статьи]

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

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

Доброго времени суток хабр.

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

Четыре месяца назад ребром встал вопрос о тексте для моего дипломного перевода. Результатом помощи коллективного разума стало решение переводить главу Scalable Web Architecture and Distributed Systems за авторством Kate Matsudaira. Нужно отметить, что это мой первый перевод такого объема и сложности. Текст, был мною относительно успешно переведен, хотя по качеству перевода я поставил бы себе 6-7 из 10. Дабы мои усилия не пропали втуне, публикую результат своих трудов.

Масштабируемая Веб-архитектура и распределенные системы zip, ~1 mb.
Если кто-либо заинтересован в улучшении качества перевода — пишите в PM, открою доступ к колаборативному переводу на translatedby.com

В последнее время, я часто слышу мнения, что “Объем отправки писем это ключ к успеху в email-маркетинге!”. По своей сути, они означают, что отправка дополнительных email приводит к большей активности подписчиков, зарабатыванию большего числа денег, и, вообще, лучше (вне зависимости от того, что “лучше” значит для вас).

Их аргументы просты:

1. Мои данные показывают, что чем больше получает/открывает/кликает мою рассылку, тем больше денег я зарабатываю.
2. Так как я не могу волшебным образом “наколдовать” новые email-адреса, поэтому я должен чаще отправлять рассылки тем, кто уже есть.

Ведь если у вас есть адресная база в 10 000 адресов и каждый раз, когда вы отправляете по ним email, вы получите 100 заказов, то, отправив email на эти адреса два раза в месяц, а не один, вы ожидаете получить на 100 заказов больше, верно? Деньги у вас в кармане! Почему бы не пойти на это?

Безусловно, рассуждения верные. Но не все так просто.

Может быть, вы сможете увеличить частоту ваших рассылок для роста продаж, а может и не сможете. И вот почему: Активность подписчика (открытия, клики) зависит от частоты отправки рассылок. Чем больше вы отправляете, тем меньше подписчиков открывают ваши рассылки и кликают по ссылкам в них. А значит должна быть точка равновесия, в которой определенная частота рассылки максимизирует активность подписчика (а, следовательно, и ваши продажи).

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

NeoLucida — оптический инструмент для рисования 19-го века, обновленный для 21 века.

Задолго до Google Glass… была камера-люцида.

— Эээ… Что?

Камера Люцида.
Это призма на палочке! Для создания реалистичных рисунков!
Раньше использовалась повсеместно.
Уже целые поколения ничего не знают о ней, камера давно не производится.
И мы её вернули.
Действительно недорого.
Для художников и студентов во всем мире.