Нам сложно себе представить, чтобы в серьезных больших компаниях с большим количеством проектов не было вообще никакой системы учета рабочего времени. Например, если вы договорились сделать клиенту проект за фиксированную цену, то как вы узнаете, сделали ли вы его в «плюс», если не посчитаете потраченное время? Как достоверно ответите на вопросы об эффективности конкретных сотрудников, точности оценок, спрогнозируете дальнейший ход проекта? Все считают рабочее время так или иначе — на бумажке, в эксельке, прикидывают на глазок по косвенным признакам, «и так знают примерно», или же решают для себя, что ценность точной информации стоит некоторого усилия.
Мы считаем, что для расчета экономики проекта нужно уметь все затраты разнести с точностью до задачи. Считать просто по количеству людей в команде недостаточно, особенно учитывая, что у нас специалисты (дизайнеры, QA, инфраструктура…) могут работать одновременно на нескольких проектах.
Не можем отвечать за всех работодателей, разочаровавших комментаторов, но вот конкретно мы используем таймшиты:
1. как информацию для финансового учета, в том числе чтобы посчитать и выставить счета заказчикам. И поскольку мы не «бодишоп»/«аутсорс», нам для этого нужно понимать содержание выполненной работы, а не просто человеко-часы;
2. как источник данных для 1С для учета отпусков, больничных, отгулов. В 1С для начисления ЗП используются табели рабочего времени.
3. для анализа фактических трудозатрат по проектам — нам очень интересно знать, на какие задачи когда и сколько времени потрачено. Для анализа комплексных проектов, в которых разные части ведутся в разных трекерах, очень удобно иметь агрегированные данные.
4. для анализа проектного портфеля в различных разрезах.
Тема логаута в SSO достаточно болезненная. Причины на поверхности, можно посмотреть тут -> https://wiki.shibboleth.net/confluence/display/CONCEPT/SLOIssues.
В примере из статьи действительно не реализован случай, когда процедура логаута инициируется на стороне idp. Shibboleth не поддерживает это из коробки. Однако есть ответвление от основной ветки shibboleth’а (https://wiki.niif.hu/ShibIdpSLO), где такая функциональность реализована. Во время написания статьи это работало. Насколько это сейчас актуально и поддерживается мы не знаем. А работает эта функциональность очень просто: в метаданных sp указывается поддержка logout’у (URL, метод, параметры). При логауте на idp берется SSO сессия и для каждого sp вызывается локальный логаут. Собственно он и реализован в Шаге 3 «Если получен запрос на logout, удаляем локальную сессию».
Кстати рекомендуем вам рассмотреть вариантами готовой интеграции sp и idp. Например, средствами спринга http://projects.spring.io/spring-security-saml/.
В качестве idp рекомендуем обратить внимание на KeyCloak. Мы писали в рамках темы безопасности об этом продукте https://habrahabr.ru/company/eastbanctech/blog/272149/.
Как часто летающий пассажир, уверены, вы знаете, что стоимость билетов в разные дни недели, на выходных и праздниках разная. Поэтому впрямую сравнивать минимально-возможный тариф и проездной нельзя. Проездной дает гарантию цены и возможность забронировать или перенести перелет в любой момент.
Это, действительно, вопрос не техники, а целесообразности проездного на направлении: коммерции этого направления, а также наличии достаточного спроса. Скажем на направлении Москва-Питер такой спрос есть и он высок, поэтому это было первое направление, выбранноедля проездного.
Как уже было сказано в тексте статьи, мы получили пользу не только от конечного результата (типизации клиентских моделей), но и от промежуточного звена (документации API) в том числе.
Скажу больше. Вначале у нас был только Swagger для документации API. И уже потом пришла идея получить заодно и клиентские модели.
Отвечая на Ваш вопрос.
Попытки познакомиться не было, т.к. пришли мы к этому решению другим путём.
Что касается упомянутых решений.
1. Netjs вижу впервые. На мой взгляд не выглядит серьезным, если смотреть на метрики github.
Да и идея другая. Больше похоже на «пишем на C#, получаем TypeScript», а не на генерацию TS definitions.
Тут интереснее подумать о «пишем Back-End на TypeScript + Node.js, переиспользуем логику на Front-End», но это уже отдельная тема.
2. TypeLITE — согласен, делает как раз то, что нужно.
И он даже попадался мне на глаза ранее, но в тот момент не получилось его внедрить по каким-то другим причинам (время, ресурсы и т.п.), а не потому что не понравился.
Попробуйте его, если таки найдете подходящий повод. И поделитесь! :)
И наконец.
Вариант с промежуточной JSON Schema имеет неоспоримое преимущество.
Он не зависит от языка на котором написан API.
Это может быть Java, C#, PHP, Ruby и т.д. Всё, что душе угодно.
Хоть вручную описать Swagger документ, и сгенерировать клиентский код.
У нас данные непосредственно из страховой. Понятно, что бывает быстро, а бывает и довольно долго. Мы привели крайний случай. Например, если у вас не новая машина, вы страхуетесь со сменой страховой компании, страхование происходит в небольшой точке продаж, а у вас еще было и ДТП, то все это не факт, что быстро. Будут требовать полностью помытую машину, фотографии в полный рост и со всех сторон, максимальный пакет документов и проверять их будут по полной.
Даже если рассматривать вариант, что кому-то интересны фото в качестве доступном для скриншотов, нужно иметь в виду, что доступ в приложение ограничен, а данные хранятся в зашифрованном виде. Конечно, если мошшеники договорятся с агентами — они смогут снять скриншоты, но тогда что мешало агенту просто фотографировать авто обычной камерой, а не специальным приложением. Без приложения доступность фото была много выше.
Ваша постановка задачи не соответствует нашей, т.к. зажечь лампочку через радиоканал и зажечь лампочку из любой точки земли с доступом в интернет не одно и то же.
Действительно термин микроконтроллер тут не совсем точен, но мы специально его ипользуем, чтобы не путать, с терминами «контроллер», который ипользуется в Java части, и «устройство» которым мы называем всю плату.
А что касается скриптовых языков, нам кажется, что ключ к распространению подобного рода решений это дешевые «микроконтроллеры» :) вроде NudeMCU, и простые и популярные языки, такие как JavaScript.
Мы сразу очертили ситуацию — заказчик выбрал для внутрикорпоративной коммуникации портал на SharePoint. Согласитесь, множить ИТ-продукты в компании не сильно правильное решение. Поэтому они и не рассматривали коробки и обратились к нам.
Да, это очень хорошее замечание. Понимание того, что в gradle-модули можно выносить не только какие-то общие библиотеки, но и разделять ими свой же проект на разные имплементации (платформозависимые или mock/real) или на разные слои, такие как view-модуль, domain-модуль, data-модуль, дает еще больше гибкости. Gradle-модули сами по себе уже мощный инструмент, который заслуживает одельного туториала :)
Никакой весомой разницы нет.
Любой из встроенных LM так же как и наш выполняет одинаковую работу: получает view от recycler, выполняет над ней measue(), что бы view сказала, какие размеры она хотела бы иметь и на основе этих размеров и следуя своей логике размещает её на экране. При этом нашему LM даже и неважно, каким размером хочет быть эта view, т.к. мы условились, что все элементы у нас или в 3/4 высоты или в полный экран, в зависимости от ориентации.
Мы считаем, что для расчета экономики проекта нужно уметь все затраты разнести с точностью до задачи. Считать просто по количеству людей в команде недостаточно, особенно учитывая, что у нас специалисты (дизайнеры, QA, инфраструктура…) могут работать одновременно на нескольких проектах.
1. как информацию для финансового учета, в том числе чтобы посчитать и выставить счета заказчикам. И поскольку мы не «бодишоп»/«аутсорс», нам для этого нужно понимать содержание выполненной работы, а не просто человеко-часы;
2. как источник данных для 1С для учета отпусков, больничных, отгулов. В 1С для начисления ЗП используются табели рабочего времени.
3. для анализа фактических трудозатрат по проектам — нам очень интересно знать, на какие задачи когда и сколько времени потрачено. Для анализа комплексных проектов, в которых разные части ведутся в разных трекерах, очень удобно иметь агрегированные данные.
4. для анализа проектного портфеля в различных разрезах.
В примере из статьи действительно не реализован случай, когда процедура логаута инициируется на стороне idp. Shibboleth не поддерживает это из коробки. Однако есть ответвление от основной ветки shibboleth’а (https://wiki.niif.hu/ShibIdpSLO), где такая функциональность реализована. Во время написания статьи это работало. Насколько это сейчас актуально и поддерживается мы не знаем. А работает эта функциональность очень просто: в метаданных sp указывается поддержка logout’у (URL, метод, параметры). При логауте на idp берется SSO сессия и для каждого sp вызывается локальный логаут. Собственно он и реализован в Шаге 3 «Если получен запрос на logout, удаляем локальную сессию».
Кстати рекомендуем вам рассмотреть вариантами готовой интеграции sp и idp. Например, средствами спринга http://projects.spring.io/spring-security-saml/.
В качестве idp рекомендуем обратить внимание на KeyCloak. Мы писали в рамках темы безопасности об этом продукте https://habrahabr.ru/company/eastbanctech/blog/272149/.
Скажу больше. Вначале у нас был только Swagger для документации API. И уже потом пришла идея получить заодно и клиентские модели.
Отвечая на Ваш вопрос.
Попытки познакомиться не было, т.к. пришли мы к этому решению другим путём.
Что касается упомянутых решений.
1. Netjs вижу впервые. На мой взгляд не выглядит серьезным, если смотреть на метрики github.
Да и идея другая. Больше похоже на «пишем на C#, получаем TypeScript», а не на генерацию TS definitions.
Тут интереснее подумать о «пишем Back-End на TypeScript + Node.js, переиспользуем логику на Front-End», но это уже отдельная тема.
2. TypeLITE — согласен, делает как раз то, что нужно.
И он даже попадался мне на глаза ранее, но в тот момент не получилось его внедрить по каким-то другим причинам (время, ресурсы и т.п.), а не потому что не понравился.
Попробуйте его, если таки найдете подходящий повод. И поделитесь! :)
И наконец.
Вариант с промежуточной JSON Schema имеет неоспоримое преимущество.
Он не зависит от языка на котором написан API.
Это может быть Java, C#, PHP, Ruby и т.д. Всё, что душе угодно.
Хоть вручную описать Swagger документ, и сгенерировать клиентский код.
А что касается скриптовых языков, нам кажется, что ключ к распространению подобного рода решений это дешевые «микроконтроллеры» :) вроде NudeMCU, и простые и популярные языки, такие как JavaScript.
Любой из встроенных LM так же как и наш выполняет одинаковую работу: получает view от recycler, выполняет над ней measue(), что бы view сказала, какие размеры она хотела бы иметь и на основе этих размеров и следуя своей логике размещает её на экране. При этом нашему LM даже и неважно, каким размером хочет быть эта view, т.к. мы условились, что все элементы у нас или в 3/4 высоты или в полный экран, в зависимости от ориентации.