Я сам не доберусь что-то окончательное придумать с этими форматами, которые так и не добрались до прохождения модерации и добавления в репозитарий — но по крайней мере добавил для тех, кто может быть будет примерно так же придумывать что-то для парсинга PSD в будущем.
Если кто-нибудь когда-нибудь доберется это все слить воедино и сделать хороший test suite для парсинга — будет хорошее подспорье, в том числе для создания проектов типа описанного в посте.
Википедия довольно подробно отвечает на этот вопрос. Если совсем коротко — то (1) используемый внутри электролит — щелочь, довольно коррозивный элемент, рано или поздно разъедающие сталь, из которой сделан корпус, (2) там есть камера для сбора газов отработавшего электролита; если газов становится слишком много, происходит разрыв мембраны.
Вытекает, соответственно, во всех этих случаях, электролит — щелочь.
Я не уверен насчет gpl'ных, но там все как-то весьма сурово, да. Как минимум, у них в лицензировании должен быть отдельный (и большой, по идее, учитывая Docker) файлик с кучей всяких лицензий хотя бы на всякое такое. Впрочем, конкретно проект ambar-crawler у них вообще без явно указанной лицензии.
мы решились на создание своего продукта, конечно же open-source'ного.
А проект хороший, да.
Только вот он ни разу не "open source", там fair source с "Use Limitation: 1 user". Так что "хороший" при наличии массы разумных open source альтернатив — по-моему, преувеличение.
Можете назвать еще хоть одну массовую, не нишевую, область, где ASN.1 используется?
Я могу назвать с десяток (вроде LDAP, SNMP, H.323, UMTS, LTE, WiMAX, 3GPP и вообще очень много всего в том, что касается телекомов и вокруг них), но вы удобно скажете, что это все "нишевые области". Впрочем, чем тогда "криптография" не нишевая?
Или даже так: работа с ASN.1 почти всегда подразумевает касание криптографии.
Если мы откроем какой-нибудь более-менее современный словарь, то прочитаем там что-то вроде: "Криптография — дисциплина, включающая принципы, средства и методы преобразования информации в целях сокрытия ее содержания, предотвращения видоизменения или несанкционированного использования."
И вот в посте ровно пример того, где работа с ASN.1 ну совсем никак не связана с использованием криптографии. Ничего не шифруется или подписывается с целью сокрытия содержания или защиты от изменений. Сертификат используется просто как источник данных. Если бы эти данные можно было получить, обратившись в какую-нибудь БД или веб-сервис — скорее всего так бы и сделали, а не разбирали сертификаты.
Только вот примерно все, описанное в топике, к криптографии не имеет ни малейшего отношения. Просто есть некий файл в ASN1/DER, который надо разобрать, понять, что внутри дерево, пройтись по нему и найти там нужное. Вместо ASN1 мог быть RIFF, TIFF, EBML, BSON, Protobuf, Apache Avro и т.д. — в общем, любой бинарный контейнер. Радикально ничего от этого не меняется.
Мир enterprise — это например биржевая роботизированная торговля, которая торгует тогда, когда работают биржи.
Окей, покажите мне хоть одну биржу или трейдерский софт на EE ;)
А вы много где видели скажем Терадату помимо банков? Я вам подскажу — еще сотовые операторы обычно кроме банков ее держат. Объемы входящих маркет данных тоже вполне себе немаленькие.
Последний раз когда я смотрел на Teradata DWH, он был написан на C++. Ну и да, по нынешним временам я бы их в пример приводить не стал, дела у них идут относительно так себе.
Одного сотового оператора наблюдаю прямо сейчас. Ничего особенно впечатляющего — ни в количестве транзакций, ни в размерах в байтах. Терадата у них живет исключительно в BI и в сильно урезанном виде. Основной внутренний рабочий DWH — Splunk.
Среднестатистический bigdata-стартап, считающий какие-нибудь рекомендации или рекламу, обрабатывает в 10-100 раз больше данных в сутки.
К тому, как вы будете общаться с внешним сервисом, будь то GPS или принтеры, это никакого отношения ровным счетом не имеет. То есть ваще никакого.
А вот микросервисная архитектура, с которой мы начинали, вполне себе имеет.
хотя утверждать что в мире enterprize не слышали о серьезных нагрузках — это сильно.
"Мир enterprise" до сих пор работает 5 дней в неделю по 8 часов с перерывом на обед. "Мир enterprise" до сих пор мыслит оперднями и на полном серьезе складывает данные в Oracle. Единицы миллиардов транзакций в год — это до сих пор национальный потолок даже для крупных банков и транспортных систем. Где здесь нагрузки?
Привязка к платформе? В каком месте?
Отлично, вот есть у меня, допустим, система документооборота, построенная на базе EE. И вот в компании захотелось, внезапно, обеспечить интеграцию с каким-нибудь готовым существующим внешним решением по GPS-трекингу своего парка грузовых автомобилей с водителями, или, например, управления очередями печати в офисных принтерах. Что будет дальше происходить? В моем представлении, в лучшем случае будет происходить написание пары десятков врапперов над этим API. В худшем (как это обычно происходит) — просто никто не будет заморачиваться, подгрузят каких-нибудь библиотек в основной компонент и подергают вызовами оттуда. А потом, когда это понадобится в каком-то другом компоненте — добавят и туда, и подергают еще и оттуда.
Что адекватное-то? Микросервисы? Так я готов поспорить, их преимущества зачастую сомнительны, потому что EE — это и есть контейнер для микросервисов. Как впрочем и OSGI.
В EE, по современным меркам, плохо, по-моему, примерно все. Неудобная (потому что бинарная и требует весьма специфичных инструментов для отладки и контроля) и медленная (потому что о каких-то серьезных нагрузках, promises и нетредовых архитектурах там и близко не слышали) messaging bus. Жесткая привязка к одной платформе — я вот сильно сомневаюсь, что кто-то в production будет сажать на шину (т.е. реализовать эти самые микросервисы) на чем-то, отличном от Java. Отсутствие простых базовых сервисов, собственно, "как сервис". Захотите какое-нибудь готовое хранилище документов от Amazon / Google, или, там, не знаю, дергать cloud'ное API для генерации картинок → в лучшем случае, все закончится проектом эдак на человекомесяц-два по написанию монструозной обертки над этим для EE. Там, где разработчик на Ruby или Node.js напишет две-три строчки и потратит 15 минут (из которых 14 будут написанием тестов), на EE это займет в десятки и сотни раз больше времени. Современный мир — гетерогенен и, хочется нам того или нет, SaaS/PaaS/IaaS зачастую дают гигантские преимущества.
Даже те сферы, где EE типично было удобно применять (типа автоматизации бизнес-процессов), сейчас дико подминают под себя, скажем, тот же Salesforce, Dynamics и SAP.
Но это на мой взгляд дурь — если бы смигрировали, получили бы приличные преимущества.
Субъективно, профит получается, если выкидывать EE отовсюду и переделывать все на что-то более адекватное и современное. Но на это, как правило, ни верхи, ни низы пойти не могут: верхи — потому, что дорого, а низы — потому что зачем терять работу?
Сейчас наблюдается тенденция вернуться обратно на Java
Я такое года 3-4 назад наблюдал. Именно когда "сбегали" одиночки в инициативном порядке и, да, тогда некоторые огребали "любитель кложи был один". Сейчас это время прошло, народ целенаправленно и осознанно начинает новые проекты на Scala или Clojure, и программисты внезапно набираются, и так далее. И implicit'ы со scalaz уже не лепят везде, где только можно, просто потому что "круто".
Сам с удовольствием перешел сначала на 7, а потом на 8, причем в первом случае реальные улучшения были минимальны.
Ради интереса и статистики — что из 8 вы используете? Какой размер codebase у мигрированных проектов?
Возможно, что у меня сильно сдвинутая выборка — но я наблюдаю, что почти все, что сейчас делается новое-модное-интересное в районе JVM — делается на Scala или, реже, Clojure. Это всякие нагруженные вычисления, статистика, кластеризация, поисковые движки, всякие агентные системы, мессаджинг, игры с массивным количеством клиентов, one-page сайты с хорошей интеграция frontend/backend и т.п.
Java я вижу почти исключительно в командах, занимающихся системами, которые зачастую существуют уже не первый десяток лет — банки, EE, какие-то относительно старые существующие веб-порталы, либо что-то, что вынуждено с таким интегрироваться. Там даже Spring + Hibernate зачастую считается чем-то прям новым и хипстерским. И, да, зачастую Java 6 и все.
Вообще, если с точки зрения терминологии — по-моему, методы с в Java всю жизнь называли generic methods, а не "параметрический полиморфизм".
Предложенный метод забавен, но упирается в то, что по сути это вызов approve() руками, вместо implicit-вызова, которое генерирует type inferring в Scala.
Что касается Java, развитие языка не стоит на месте, язык меняется в лучшую сторону, вбирая в себя решения и конструкции из других языков.
Субъективно, Java как сам язык имеет дикое количество родовых травм и при попытке добавлять туда какие-то современные элементы функциональщины а ля Scala прямо все сурово трещит по швам, в первую очередь в районе системы типов. По крайней мере из того, что я вижу — программистов на "современной Java" сейчас уже сильно меньше, чем программистов на той же Scala. Приличная масса до сих пор сидит в лучшем случае на 7 (а то и на 6), или, даже если меняли компилятор — все равно в code base используют все те же практики 15-летней давности.
JVM же как раз развивается полезно, но как-то странно. Появляется масса интересных оптимизаций, JVM 8 действительно стала прямо летать на куче всяких интересных задач, но опять же — радикальных изменений в районе той же системы типов — так и не происходит. Фактически, JVM как ничего не знал о generics — так и не знает. Как была одна куцая инструкция instanceof — так, фактически и остается. Как плодятся классы на каждый чих для функциональных проявлений — так и плодятся, разве что благодаря более эффективным GC стало не так заметно.
Про ответственность — если бы сотрудники и владельцы ресурса оказались несколько менее вменяемыми — легко можно было бы иметь как минимум 159.6 УК РФ или 146, если не 272. Для следователя все вообще шикарно — состав преступления налицо — и человек все сам в письме написал и подтвердил (признает, извиняется и раскаивается), и в платежной системе все прошло, и личные координаты все видны из-за используемой карточки → банк выдаст моментально.
Я сам не доберусь что-то окончательное придумать с этими форматами, которые так и не добрались до прохождения модерации и добавления в репозитарий — но по крайней мере добавил для тех, кто может быть будет примерно так же придумывать что-то для парсинга PSD в будущем.
Если кто-нибудь когда-нибудь доберется это все слить воедино и сделать хороший test suite для парсинга — будет хорошее подспорье, в том числе для создания проектов типа описанного в посте.
Забавно :)
Мне был известен только спецификация PSD в формате Kaitai Struct за авторством David Hicks:
https://github.com/kaitai-io/kaitai_struct_formats/issues/138
https://github.com/davidhicks/kaitai_struct_formats/tree/psd
Не возражаете, если я добавлю ссылку на вашу работу в общий тикет, где это обсуждается?
В какой-то степени завезли. Хотя бы версию C++ или всякие там "хочу в целом собираться с отладкой" можно указать.
Википедия довольно подробно отвечает на этот вопрос. Если совсем коротко — то (1) используемый внутри электролит — щелочь, довольно коррозивный элемент, рано или поздно разъедающие сталь, из которой сделан корпус, (2) там есть камера для сбора газов отработавшего электролита; если газов становится слишком много, происходит разрыв мембраны.
Вытекает, соответственно, во всех этих случаях, электролит — щелочь.
Я не уверен насчет gpl'ных, но там все как-то весьма сурово, да. Как минимум, у них в лицензировании должен быть отдельный (и большой, по идее, учитывая Docker) файлик с кучей всяких лицензий хотя бы на всякое такое. Впрочем, конкретно проект ambar-crawler у них вообще без явно указанной лицензии.
Только вот он ни разу не "open source", там fair source с "Use Limitation: 1 user". Так что "хороший" при наличии массы разумных open source альтернатив — по-моему, преувеличение.
ioctl не нужен, вполне отдается через sysfs обычному пользователю: см., например,
/sys/bus/scsi/devices/0:0:0:0/wwidЕсли речь про DMI, то да, там обычно нужен либо доступ к /dev/mem, либо к чему-нибудь в районе /sys/firmware/dmi — и там тоже все только для root.
Мы в свое время писали Einarc для этого.
/facepalm %)
Зато вот нас точно забыли ;)
Я могу назвать с десяток (вроде LDAP, SNMP, H.323, UMTS, LTE, WiMAX, 3GPP и вообще очень много всего в том, что касается телекомов и вокруг них), но вы удобно скажете, что это все "нишевые области". Впрочем, чем тогда "криптография" не нишевая?
Если мы откроем какой-нибудь более-менее современный словарь, то прочитаем там что-то вроде: "Криптография — дисциплина, включающая принципы, средства и методы преобразования информации в целях сокрытия ее содержания, предотвращения видоизменения или несанкционированного использования."
И вот в посте ровно пример того, где работа с ASN.1 ну совсем никак не связана с использованием криптографии. Ничего не шифруется или подписывается с целью сокрытия содержания или защиты от изменений. Сертификат используется просто как источник данных. Если бы эти данные можно было получить, обратившись в какую-нибудь БД или веб-сервис — скорее всего так бы и сделали, а не разбирали сертификаты.
Только вот примерно все, описанное в топике, к криптографии не имеет ни малейшего отношения. Просто есть некий файл в ASN1/DER, который надо разобрать, понять, что внутри дерево, пройтись по нему и найти там нужное. Вместо ASN1 мог быть RIFF, TIFF, EBML, BSON, Protobuf, Apache Avro и т.д. — в общем, любой бинарный контейнер. Радикально ничего от этого не меняется.
Окей, покажите мне хоть одну биржу или трейдерский софт на EE ;)
Последний раз когда я смотрел на Teradata DWH, он был написан на C++. Ну и да, по нынешним временам я бы их в пример приводить не стал, дела у них идут относительно так себе.
Одного сотового оператора наблюдаю прямо сейчас. Ничего особенно впечатляющего — ни в количестве транзакций, ни в размерах в байтах. Терадата у них живет исключительно в BI и в сильно урезанном виде. Основной внутренний рабочий DWH — Splunk.
Среднестатистический bigdata-стартап, считающий какие-нибудь рекомендации или рекламу, обрабатывает в 10-100 раз больше данных в сутки.
А вот микросервисная архитектура, с которой мы начинали, вполне себе имеет.
"Мир enterprise" до сих пор работает 5 дней в неделю по 8 часов с перерывом на обед. "Мир enterprise" до сих пор мыслит оперднями и на полном серьезе складывает данные в Oracle. Единицы миллиардов транзакций в год — это до сих пор национальный потолок даже для крупных банков и транспортных систем. Где здесь нагрузки?
Отлично, вот есть у меня, допустим, система документооборота, построенная на базе EE. И вот в компании захотелось, внезапно, обеспечить интеграцию с каким-нибудь готовым существующим внешним решением по GPS-трекингу своего парка грузовых автомобилей с водителями, или, например, управления очередями печати в офисных принтерах. Что будет дальше происходить? В моем представлении, в лучшем случае будет происходить написание пары десятков врапперов над этим API. В худшем (как это обычно происходит) — просто никто не будет заморачиваться, подгрузят каких-нибудь библиотек в основной компонент и подергают вызовами оттуда. А потом, когда это понадобится в каком-то другом компоненте — добавят и туда, и подергают еще и оттуда.
В EE, по современным меркам, плохо, по-моему, примерно все. Неудобная (потому что бинарная и требует весьма специфичных инструментов для отладки и контроля) и медленная (потому что о каких-то серьезных нагрузках, promises и нетредовых архитектурах там и близко не слышали) messaging bus. Жесткая привязка к одной платформе — я вот сильно сомневаюсь, что кто-то в production будет сажать на шину (т.е. реализовать эти самые микросервисы) на чем-то, отличном от Java. Отсутствие простых базовых сервисов, собственно, "как сервис". Захотите какое-нибудь готовое хранилище документов от Amazon / Google, или, там, не знаю, дергать cloud'ное API для генерации картинок → в лучшем случае, все закончится проектом эдак на человекомесяц-два по написанию монструозной обертки над этим для EE. Там, где разработчик на Ruby или Node.js напишет две-три строчки и потратит 15 минут (из которых 14 будут написанием тестов), на EE это займет в десятки и сотни раз больше времени. Современный мир — гетерогенен и, хочется нам того или нет, SaaS/PaaS/IaaS зачастую дают гигантские преимущества.
Даже те сферы, где EE типично было удобно применять (типа автоматизации бизнес-процессов), сейчас дико подминают под себя, скажем, тот же Salesforce, Dynamics и SAP.
Субъективно, профит получается, если выкидывать EE отовсюду и переделывать все на что-то более адекватное и современное. Но на это, как правило, ни верхи, ни низы пойти не могут: верхи — потому, что дорого, а низы — потому что зачем терять работу?
Я такое года 3-4 назад наблюдал. Именно когда "сбегали" одиночки в инициативном порядке и, да, тогда некоторые огребали "любитель кложи был один". Сейчас это время прошло, народ целенаправленно и осознанно начинает новые проекты на Scala или Clojure, и программисты внезапно набираются, и так далее. И implicit'ы со scalaz уже не лепят везде, где только можно, просто потому что "круто".
Ради интереса и статистики — что из 8 вы используете? Какой размер codebase у мигрированных проектов?
Возможно, что у меня сильно сдвинутая выборка — но я наблюдаю, что почти все, что сейчас делается новое-модное-интересное в районе JVM — делается на Scala или, реже, Clojure. Это всякие нагруженные вычисления, статистика, кластеризация, поисковые движки, всякие агентные системы, мессаджинг, игры с массивным количеством клиентов, one-page сайты с хорошей интеграция frontend/backend и т.п.
Java я вижу почти исключительно в командах, занимающихся системами, которые зачастую существуют уже не первый десяток лет — банки, EE, какие-то относительно старые существующие веб-порталы, либо что-то, что вынуждено с таким интегрироваться. Там даже Spring + Hibernate зачастую считается чем-то прям новым и хипстерским. И, да, зачастую Java 6 и все.
Вообще, если с точки зрения терминологии — по-моему, методы с в Java всю жизнь называли generic methods, а не "параметрический полиморфизм".
Предложенный метод забавен, но упирается в то, что по сути это вызов approve() руками, вместо implicit-вызова, которое генерирует type inferring в Scala.
Субъективно, Java как сам язык имеет дикое количество родовых травм и при попытке добавлять туда какие-то современные элементы функциональщины а ля Scala прямо все сурово трещит по швам, в первую очередь в районе системы типов. По крайней мере из того, что я вижу — программистов на "современной Java" сейчас уже сильно меньше, чем программистов на той же Scala. Приличная масса до сих пор сидит в лучшем случае на 7 (а то и на 6), или, даже если меняли компилятор — все равно в code base используют все те же практики 15-летней давности.
JVM же как раз развивается полезно, но как-то странно. Появляется масса интересных оптимизаций, JVM 8 действительно стала прямо летать на куче всяких интересных задач, но опять же — радикальных изменений в районе той же системы типов — так и не происходит. Фактически, JVM как ничего не знал о generics — так и не знает. Как была одна куцая инструкция instanceof — так, фактически и остается. Как плодятся классы на каждый чих для функциональных проявлений — так и плодятся, разве что благодаря более эффективным GC стало не так заметно.
Про ответственность — если бы сотрудники и владельцы ресурса оказались несколько менее вменяемыми — легко можно было бы иметь как минимум 159.6 УК РФ или 146, если не 272. Для следователя все вообще шикарно — состав преступления налицо — и человек все сам в письме написал и подтвердил (признает, извиняется и раскаивается), и в платежной системе все прошло, и личные координаты все видны из-за используемой карточки → банк выдаст моментально.
При этом еще в 2010 году в комментариях все обсуждают, что ant уже безнадежно неактуален и смысла о нем говорить нет ;)