Примечание: код для этой статьи выложен на мой Github [здесь].

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

Когда любая ветвь дерева разделяется, сумма площадей поперечного сечения сохраняется.

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

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

При помощи этой методики можно генерировать высококачественные меши деревьев на разных этапах роста в реальном времени и с незначительной тратой вычислительных ресурсов!

Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.

• Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
• Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
• Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
• Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.

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

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

Что такое магия в PHP? Обычно под этим подразумевают методы вроде _construct() или __get(). Магические методы в PHP — это лазейки, которые помогают разработчикам выполнять удивительные вещи. В сети полно инструкций по их использованию, с которыми вы наверняка знакомы. Но что если мы скажем, что вы даже не видели настоящую магию? Ведь, чем больше вам кажется, что вы знаете все, тем больше магии ускользает от вас.



Давайте отбросим установленные рамки правил ООП и сделаем невозможное возможным в школе магии PHP. Главный и первый волшебный преподаватель школы — Александр Лисаченко (NightTiger). Он научит магическому мышлению и, возможно, вы полюбите магические методы, нестандартные способы доступа к свойствам, изменение контекстов, аспектно-ориентированное программирование и потоковые фильтры.

Получилось так, что с 2012 года я курирую московский Techstars Startup Digest. Это — email-рассылка мероприятий для IT-специалистов, основателей стартапов и маркетологов.

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

Интересно, что в последнее время большая часть таких мероприятий проходит в коворкингах. Что удивительно, по моим наблюдениям, количество подобных площадок в Москве растет.

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

На Хабре я пока показал только #tceh, SOK и Ключ, а в период новогодних каникул переключился на изучение «мат.части», чтобы посмотреть, какие книги рассказывают об эволюции рабочего пространства: от первых опенспейсов 1900-х годов до коворкингов.

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

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

У меня иногда складывается впечатление, что не он служит для нас, а мы служим для этого формата. Поэтому — сэр Markdown.

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

Мне нравится записывать полезные вещи об интерфейсах, свойствах, методах, функциях, типах данных, и обо всём прочем, что относится к веб-разработке. Так я заполняю пробелы в знаниях. Сейчас я занят документацией к Node.js, а до этого проработал материалы по HTML, DOM, по Web API, CSS, SVG и EcmaScript.

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

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

Здорово было бы найти способ заставить компьютер сэкономить вам время и решить проблемы, о которых я сказал выше… И именно тут на помощь приходит процедурная генерация!

Очень часто на тостере вижу вопросы вида «Как отсортировать массив в JavaScript по определенному правилу?», «Как сделать с массивом в JavaScript <действие>?» и т.д.

Под катом собраны некоторые манипуляции над массивами.

Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

Маленький рассказ о том, как наша команда решила организовать иконки в грядущем проекте. Чуть-чуть исторического экскурса, взгляды по сторонам (на PNG и векторные шрифты) и рассказ о том, как мы всё-таки обустроились в итоге.

Иконки у нас используются, и активно – хорошо подобранная иконка заменяет слова и предложения (а фигово подобранной иконке можно сделать всплывающую подсказку, но не будем о грустном)

В общем, есть (и продолжают создаваться) иконки. Надо их положить на веб-страницу. Надо сделать это так, чтобы потом голова не болела про них весь остаток проекта и ещё пару лет в поддержке. Ну и есть дополнительные хотелки:

• хочется вектора. Ну, ладно, вектор – это средство, а не цель. Цель – не беспокоиться ВООБЩЕ об изменении размеров, ретина дисплеях, сохранении изображения в разных форматах для разных целей.
• хочется стилизации иконок. Потому что у нас из коробки как минимум два набора тем (светлая и тёмная), а то и контрастная, для людей с нестандартным зрением, а то и оранжевенькая какая-нибудь появится ближе к Новому году… В общем – одна и та же по сути иконка должна выглядеть слегка иначе в зависимости от выбранной на странице темы.
• хочется динамической стилизации иконок. Статики – нам мало. Этого хватает для скриншотиков и рекламных буклетиков, но не для живых пользователей. А мы хотели жизни! Мы хотели ховера! Мы хотели селекшена!!! И дизаблить, дизаблить их всех!.. Извините.
• НЕ хочется, чтобы в этом участвовал JavaScript в любой его форме и проявлении. Иконки – это внешний вид, а за него ответственный HTML + CSS. Ну, ладно, класс selected я готов навесить на элементы, но это последняя граница…

Есть и факторы, облегчающие задачу. Иконки сейчас (2015, осень, начинает снежить) в моде плоские, строгие. Если лет пять назад иконки пестрели, то сейчас это ушло под влиянием МС, Эппла, Материал Дизайна…

tl;dr Внимание. Следующие несколько разделов – это расплывание мыcлею по древу, причём вширь, обзор решений (в том числе – неудачных) и котик в разных ракурсах.
Кому хочется технических подробностей того, что же вышло в итоге – пожалуйте сюда.

Начало

У меня есть увлечение – коллекционировать слитые в интернет базы и прочий «хлам». Как-то раз решил я пошарить на RGhost в поисках «вкусненького». Часто на файлообменниках обнаруживаю инструкции по подключению к чему угодно с вложенными туда логинами и паролями. В этот раз совершенно случайно наткнулся на 700 MB текстовый файл «dump.txt», в котором красиво лежали пары логин-пароль. Сначала огорчился: «Наверное, это всем доступные, собранные вместе, совсем недавно слитые учетные записи Яндекса, Мейла, Google», — подумал я. Но нет… Немного изучив находку, я обомлел.

Я никому не открою Америку, не удивлю публику новым фокусом и не взорву мозг тем, кто в CSS3 плавает, как аквалангист. Расскажу простой способ, как создать слайдер с помощью простых функций CSS3 без необходимости использовния javascript.

Как мы избавились от JavaScript-библиотек социальных сетей, ускорили скорость загрузки страниц и использовали RESTful API для “шаринга” и “лайков”.

Посмотрите на это фото.



Это совершенно обычная фотография, найденная в Гугле по запросу «железная дорога». И сама дорога тоже ничем особенным не отличается.

Что будет, если убрать это фото и попросить вас нарисовать железную дорогу по памяти?

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

Когда меня развернули на 180 градусов в аэропорту перед полётом в Грецию, я начал звонить в сервисы по билетам и отелю. AWAD, фактически, положил на меня как на клиента – «посмотрите на сайте», «войдите в личный кабинет» и так далее. С другой стороны, Букинг внимательно выслушал, в прямом эфире набрал отель и чётко перенёс моё бронирование, пока я шёл к аэроэкспрессу. Хотя в правилах отеля если что не так – постоялец идёт на хрен. Так я оценил разницу в сервисе.

Но я не про это. Дело в том, что Букинг предложил мне контракт на проверку адекватности перевода их сайта на русский. Сразу покажу, с чего началось:



А вот чем продолжилось:



А теперь расскажу и покажу, что и как с текстами интерфейсов.

Много времени прошло с момента появления AngularJs (в масштабах веб-технологий конечно). Сейчас в интернетах есть огромное количество постов восхваляющих этот фреймворк до небес, что это манна небесная не иначе, а критики не так уж и много как он того заслуживает. Но такие статьи уже потихоньку начинают появляться, и меня это радует, надеюсь индустрия переболеет ангуляром так же, как переболела MooTools, Prototype, %какой-нибудь новый язык под JVM%, %другая-супер-революционная-технология%. Не знаю почему, но в IT-области такие революционные технологии, которые поднимают шум, а потом пропадают, появляются довольно часто. Хороший разработчик должен уметь отличать очередную модную технологию, от работающего инструмента. И для этого очень важно критически смотреть на вещи. Моя статья — это компиляция самых весомых выводов из других статей, и моих личных умозаключений. Ангуляр создает хороший вау-эффект, когда видишь его впервые: «ух ты, я написал ng-repeat, и реализовал эту логику одними тегами и все само обновляется!», но как только приходится реализовывать реальные приложения, а не очередной TODO-лист, то все становиться очень печально. Сразу хочу сказать, что фреймворк я знаю хорошо, даже больше чем мне хотелось бы его знать, я программировал на нем в течении 2 лет. И для следующего проекта я его точно не выберу, и это хорошо, все мы учимся на ошибках. Так что же не так с ангуляром? Тут нет однозначного ответа, слишком много разных недостатков, которые создают такой облик фреймворку. Если одним словом – непродуманная архитектура. Под катом я привожу конкретику, так что устраивайтесь поудобнее. ДА НАЧНЕТСЯ ХОЛЛИ ВАР!

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

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

А бюджет у гостиницы или отеля — самое больное. И вот его-то можно сильно сократить, если начать проект чуть заранее.

Как заработать миллион за день, стать искусным оратором за неделю, похудеть на 100 кг за 2 дня, стать успешным в тысяча ста начинаниях и прочая мишура регулярно засоряет наше информационное пространство. А порой так хочется взять в руки книгу, которая не просто съест кусок вашего свободного времени повествуя о неприменимых в отечественных реалиях вещах, но и подкинет хотя бы несколько полезных советов, способных оказать позитивное влияние на развитие вашей личности и вашего проекта.

Если вы хотите найти и/или поделиться хорошими книгами, добро пожаловать под кат.