TL;DR: Из чего состоит красивый закат? Как предсказать эти элементы заката? Откуда взять данные для предсказаний?

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

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

Элементы заката

1. Небо в том месте, где солнце заходит за горизонт.

Если небо в этом месте чистое — это красиво.
Если чистая полоска неба, а над этим облака — еще красивее.
Если есть небольшая облачность и Солнце заходит посреди облаков — тоже неплохо.
Если всё небо возле горизонта в облаках — плохо.

Примеры:


Солнце заходит без облаков на горизонте

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

Что именно будем генерировать — не так важно.
Важно что мы опишем 3 вида объектов на основе которых сгенерируем взаимодействие фронтенда с бекендом, а кое где и полностью реализацию бекенда

Эти типы объектов:
1. Messages — объекты, которые будучи сериализoванными в JSON участвуют в обмене информации между фронтендом и бекендом
2. Endpoints — URI, который вызывает фронтенд вместе с описанием HTTP метода, параметров запроса, типа Request Body и типа респонса
3. Entities — Это такие messages, для которых них есть стандартные endpoints для Create/Update/List/Delete (может быть не все), они хранятся в базе данных и для них есть Data Access Object, или Spring JPA repository — вообщем зависит от технологии, но какой то доступ к базе данных

Фронтендом я не занимаюсь вообще, но
1) Знаю, что он пишется на Typescript, поэтому мы генерируем и классы тайпскрипта
2) Большая часть требований к бекенду приходит от разработчиков фронтенда.

Требования к коду

Я хочу показать три парадигмы асинхронного программирования — callbacks, futures, coroutines на примере простого веб приложения на фрейморке Vertx. Код будем писать на Котлине.

Допустим у нас есть приложение, которое получает некую строку в HTTP запросе, по ней ищет URL в базе данных, идет по этому URL и его содержимое отправляет обратно клиенту.
Vertx задуман как асинхронный фрейворк для высоконагруженных приложений, использует netty, new IO, event bus

Мне нужно было в рантайме вычислять истинность выражений типа

a>10 && b<c+5 && (a+b)<c*4

находящихся в строке Скалы.

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

Я оценивал разные библиотеки на то 1) могу ли они сделать то, что надо 2) скорость исполнения

Были проверены

• интерполяция строк
• Js Engine
• javaluator
• exp4j
• evalEx
• mxparser
• MathEval
• Groovy
• Jexl

Результаты

Время пробега в мс для 1000 выражений (вернее одно и тоже выражение для 1000 разных набoров 3х переменных):

js	239 ms
mxParser	56713 ms
evalex	35 ms
groovy	118 ms
Jexl	62 ms

Остальные способы/библиотеки не сработали.

Под катом подробности:

Андромеда. Не из города, но и без телескопа.

Для того, чтобы фотографировать deep sky объекты нужна и дорогая техника (телескопы с большим зеркалом, маунт с двигателем и т.д.) и выезд за город — там, где нет засветки.

А что делать тем, у кого нет денег на дорогую технику, нет места на хранение 10 дюймовых рефлекторов и нет времени регулярно ездить в пустыню?

Я вот и пытаюсь понять, что делать в таком случае, когда снимать Deep Sky (т.е. туманности, галактики звездные скопления) очень хочется.

Во первых нужны длинные выдержки, для этого я взял Skytracker экваториальный маунт для фотоаппарата (в продаже появилось уже следующее поколение этого маунта).

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

Слушал беседу с участниками проекта SpaceIL — посадка израильского аппарата на Луну в рамках Google Moon X Prize

1. Идея участвовать в соревновании пришла при посиделках с виски
2. Масса маленькая, поэтому нет разгонной и посадочной ступени — все в одном аппарате
3. Они первые из участников Google Moon X Prize заключили контракт на пуск — на 2017, попутная нагрузка у SpaceX (я тоже пожертвовал на это деньги)
4. Более 30 человек работают над проектом не считая добровольцев, из них 20 на полную ставку
5. Деньги от израильких бизнесменов и фирм, некоторые фирмы помогают не деньгами, а оборудованием. Гос деньги не участвуют (условие Google Moon X Prize)

Я попробую привести пример, когда бывает нужен Spring custom scope.

Мы — компания B2B и SAAS, и у нас бегут по таймеру некие долгие процессы для каждого из клиентов.
У каждого из клиентов есть какие то свойства (имя, тип подписки и т.д.).
Раньше мы делали наши сервисы prototype бинами и передавали каждому из них в конструкторе все необходимые свойства клиента и запущенного процесса (flow — имеется ввиду логический процесс, job, а не процесс ОС):

SpaceIL — израильская некоммерческая организация, участник соревнования Google Lunar X Prize.

Напомню, что Google обещала приз в 20 миллионов долларов тому, кто сможет без помощи государства посадить аппарат на Луну, проехать не менее 500м и передать видео высокого разрешения.

Израильская команда собрала уже около 30 мл долларов пожертвований и сейчас начала сбор денег на indiegogo, для оплаты запуска.

Идея SpaceIL состоит в том, что будет гораздо дешевле преодолеть 500м (нужные по условиям X Prize) взлетев и сев опять, чем везти с собой ровер.

Запуск должен быть попутным (т.е. на ракете с основной полезной нагрузкой) в мае 2015

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

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

Ну, как пример — есть кластер из нескольких веб или application серверов и пользователь делает аплоад файлу. Если тот же пользователь через 5 минут зайдет на сайт с другого компьютера и лоад балансер ему даст другой сервер из кластера, он должен всё равно увидеть загруженный им файл.

Как это можно сделать?

Я смотрел на простой NFS — но там получается есть single point of failure — компьютер, на котором этот диск родной
Я смотрел на xtreemeFS — но просто не получается его настроить работать с replication

Какие еще есть решения?

Спасибо

Мне пришлось за последние пару дней просмотреть много систем управления проектами и хочется поделиться тем, что я нашел…

Мы искали варианты с хостингом у создателя софта, чтобы не возиться с инсталяцией у себя (поэтому, например, тут нет Redmine в чистом виде).
Мне была важна интеграция с Google calendar и github.

Также хотелось чего то большего чем Bug tracking — еще и управление фичерами, требованиями и т.д.

Прошу прощения за много терминов на английском.

Картинки по клику открываются в полный размер

UPD: я не претендую на то, что просмотрел все такие сайты. их очень много!!!

В камере Sony NEX-6 можно покупать приложения, ну так же как вы покупаете для своих смартфонов.

Полный список приложений тут: https://www.playmemoriescameraapps.com/portal/

Я сначала скачал бесплатное приложение, дающее возможность управлять камерой со смартфона — камера начинает работать как Wifi spot, к ней подключается телефон и вы видите на нем то, что видит камера, можете ввести экспокоррекцию, нажать на спуск, посмотреть результат. Очень прикольно. Можно поставить в женскую баню и смотреть из за стенки

Затем я купил следующие приложения (купить было непросто, т.к. официально в Израиле их не продают):

1. Time lapse.

Позволяет камере делать снимки через определенные промежутки времени, а потом или сохранять это как много снимков или делать из них видео.

Вот результат:

Меня давно волновал вопрос — на чём проще всего сделать веб приложение ява программисту неискушенному в веб разработке.

Меня смущали несколько вещей — во первых — регистрация пользователей, логин, права доступа и так далее. Не хотелось с этим много возиться. Решение здесь я нашел в Grails с плагином Spring Security.

Во вторых — хостинг. Если писать на Яве (а мне так комфортнее всего, я на Яве с 1996 года), то хостинг дорогой. Платить по 15-20 долларов в месяц за сайты-эксперименты не хотелось.

И вот, наконец я нашел решение. Это — Gaelyk. Groovy фреймворк для Google App Engine.

Чтобы понять что он даёт и как его использовать давайте посмотрим на простейший проект.

Простейший проект можно сделать скачав template project или воспользовавшись maven archetype

Однако же первый из них использует gradle, а не maven и оба используют стандартный groovy компилятор, а не экслипсовский, который позволяет не создавать стабы, и оба не создают пример работы с Google datastore

Поэтому я создал свой maven archetype. Давайте с его помощью и создадим Gaelyk проект:

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

Проблема в то, что грувлеты — это всё таки сервер, а у нас есть еще толстый клиент на Swing. Для него мне хотелось бы сделать нечто похожее, но встраивание какого нибудь embedded Jetty или Tomcat только для этого в клиент выглядело как то слишком.

По счастью, мне попалась на глаза и другая статья — про наличие в стандартной библиотеке Java простейшего веб сервера. Вот им то я и решил воспользоваться.

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

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

Часто подобные тесты могут занимать много времени, даже если использовать in-memory базу данных (я, кстати проверял почему — у нас много JPA entities с множеством свойств в каждом и инициализация Hibernate, имено она, занимает десятки секунд!)

Значит нам надо сделать так, чтобы по умолчанию эти тесты, в отличие от обычных юнит тестов, не исполнялись во время билда.

Так что план такой:
1. Пишем сервисы, разбитые на два слоя приложения
2. Соединим их Спрингом
3. Напишем тест пользуясь JUnit для взаимодействия этих сервисов (настоящих, без всяких mock)
4. Делаем так, чтобы этот тест не бежал по умолчанию во время билда
5. Profit!

Groovy можно использовать по разному — для скриптов, для Grails, для быстрого написания прототипов, для DSL и т.д.

Меня же Groovy всегда привлекал как улучшенная Java. В самом деле — почти любой Java код будет валидным кодом Groovy — т.е. если не помнишь как что то делать в Groovy-way, можно всегда писать так, как принято в Java, а если помнишь — вот тебе и Closures, и удобные списки, и много других замечательных вещей.

Единственное, что мешало использовать Groovy для разработки production кода — отсутствие ошибок компиляции в большом числе случаев. Например если вызываешь несуществующий метод, обращаешься к несуществующей переменной и т.д.

Для многих Groovy фреймворков и библиотек это реально нужно (см. например работу с XML в Groovy), но если я пишу обычный код, мне это серьезно мешает.

Так вот, наконец в Groovy 2.0 появилась возможность сказать — проверяй в этом классе типы, существование методов и переменных!

Наш проект мы пишем с индусами.

Общую архитектуру я задал как архитектор проекта — Java, Spring и т.д.
Но в тех областях, в которых им надо было писать они сами решали что и как будет.
А привыкли они всё делать на C/C++.

В итоге родился такой монстр:

У нашей программы есть command line клиент.
Он работает с командами и скриптами на Tcl (потому что так привыкли клиенты).
Используется native Tcl Interpreter (а не JTcl) (потому что так решили наши индусы).
Команды реализованы на Java, но часть команд обращается к коду на C++ (legacy code)
Однако же система сообщений об ошибках и предупреждениях реализована на Java.
Индусы писали используя JNI, а я связь Java с С делал на JNA

Как выглядит работа команды набранной в коммандной строке?

У нас и rich client, и сервер активно используют Spring. И очень быстро возникла проблема — как использовать спринг бины из обычных классов (которые сами — не бины).

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

Вскоре я нагуглил в интернетах такой красивый вариант:

Хочу поделиться двумя историями с одинаковым сюжетом, но разными развязками.
Может быть кому то, у кого тоже падает JVM будет полезно

1. Native code вызывается из Явы через JNI. Юнит тест — проходит на ура, приложение (GUI, Swing) крэшится.
Подключаемся через дебагер ddd (это такая оболочка над gdb, ежели кто из яваистов не знает :) ) — видим что падает с длинющим стеком. Выясняем с автором нативной библиотеки, что там они десериализуют через boost (такая библиотека для C++) дерево большой глибины. И там рекурсия.

Возникает идея (не сразу, 3 дня споров и гугления), что при вызове из приложения стек больше и он переполняется. Находим параметер для JVM: -XX:ThreadStackSize=

Работает!

2. Native code вызывается через JNA. Присутствую колбеки обратно в Явы, так как я описывал. Юнит тест бежит, приложение падает!

Хочу рассказать поучительную историю.
Работает со мной мужик, который сразу после университета пришел в нашу компанию.
Сначала это был небольшой израильский стартап, потом его купила большая американская компания.
Мужик в фирме рос, руководил отделом. Так прошло 12 лет и мужик решил менять место работы.
И вдруг оказалось, что он никому не нужен.
Почему?
Дело в том, что в нашей фирме придумали свой язык, объектно ориентированный. И даже сделали его стандартом (IEEE) в области тестирования дизайна чипов.
Язык оказался удачным и на нём начали писать свой софт.
Так вот этот мужик, почти всё время, эти 12 лет, писал на этом нашем языке. (Кроме этого — на C++ и Perl, но немного.)

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

Мой первый рассказ был об американцах.
Сегодняшний — об индусах.

С индусами я работаю много. Есть даже в фирме «мой» индус — архитектор как и я, который вместе со мной отвечал за Business Logic нашей новой аппликации. В то время мы с ним говорили по мессенджеру или по телефону каждый день, я его опекал во время визитов в Израиль, свозил по своей инициативе в Иерусалим и даже приглашал домой.

У меня с ним отличные отношения (хотя и не без трений), но, как выяснилось, не всё я делал правильно :)

Во первых всё, что я писал об американцах в плане «мягких» выражений — верно для индусов и вообще для всех. При общении с кем угодно лучше сказать «Отличная идея, у меня только несколько поправок» в ситуации когда Вы думаете «Что за чушь!?».

Но есть своя специфика. Вопросы рассовой политкорректности индусов волнуют меньше, а вот вопросы «потери лица» — больше.