Аналогично, приходит либо смс, либо бумажное уведомление. Мои 2 посылки реально 2 с лишним месяца лежали в Москве и только сейчас дошли до нашего отделения в регионе. Сегодня утром как-раз ходил их забирать и просто обалдел! Я ожидал, что на почте как обычно будет очередь человек 10. Не было ни одного, это просто фантастика, никогда такого не было!
Работницы почты в опрятной униформе, сами какие-то очень деловые. Раньше абсолютно всегда были в произвольной одежде, неспешные, недовольные. Я не знаю, что с ними произошло, но это просто небо и земля! Пока сотрудница ходила за моей посылкой, слышал как одна отчитывала другую на «Вы», мол, почему Вы опоздали, рабочий день начинается в 7:45, по новым правилам за этим строго следят. На «Вы»!
Не знаю, что у них там произошло, но для меня посещение почты сегодня утром было просто приятным шоком! Будто попал на съемки фильма или какого-то розыгрыша.
Тормоза именно из-за SVG и DOM, а не d3.js как такового. С помощью d3.js можно рисовать и на HTML Canvas, и на WebGL, и даже одновременно на SVG и Canvas. Скорость при этом будет совершенно другая. Недостаток Canvas очевидно в том, что с ним сложнее делать интерактивные рисунки со всплывающими при наведении подсказками, с перетаскиваемым узлами и т.п. Но по-моему я это как-то делал, хотя и сложнее чем с SVG. Наверное можно рисовать интерактивные вещи (например, узлы графа) в SVG, а не интерактивные (связи) в Canvas, но я сам так не делал.
Присоединяюсь насчет EMS. Сначала пытались доставить домой в рабочее время. Договорились на выходной, целый день ждал курьера, а он просто не пришел, а на сайте отметка «неудачная попытка доставки». Несколько раз звонил им. В итоге доставили на неделю позже.
Кстати, ещё почти одновременно сделал 8 заказов на алиэкспрес с обычной доставкой (в регион, не Москва). Один пришел через 2 недели — мега-быстро! 5 заказов через 1-2 месяца. И по двум только сейчас, спустя 3 месяца пришло уведомление, что можно забрать, когда я уже отчаялся их получить. Причем, судя по трекеру, они в Москве были ещё пару месяцев назад. Что с ними происходило всё это время неизвестно. За это время их спокойно могли пару раз отправить назад и повторно отправить.
Sirius — это надстройка над GMF. GMF отвечает за отрисовку объектов, их перетаскивание, всякие панели инструментов и т.п.
В Sirius разработчик 1) обычно берет готовое (или создает новое) декларативное описание языка моделирования в виде Ecore-модели. Эта Ecore-модель содержит описание видов сущностей, видов отношений, которые есть в языке (например, роли, варианты использования, наследование и т.п.) Для UML, BPMN и т.п. уже есть готовые Ecore-вские модели. Для своего языка моделирования такую модель сделать достаточно просто.
Затем разработчик уже с помощью непосредственно Sirius также в декларативном виде описывает как эти элементы языка моделирования должны отрисовываться, какие для них возможны действия (создание, удаление, перетаскивание). И всё. Дальше под два этих декларативных описания частично вручную, частично на лету генерится Java-код редактора диаграмм.
При этом редактор диаграмм получается внешне и функционально практически не отличим от редакторов того же Rational Software Architect, потому что последний того же основан на GMF.
В принципе, в будущем вместо GMF может использоваться какой-то другой фреймвок для отрисовки, в том числе и на основе HTML Canvas. Eclipse активно движется в этом направлении. При этом разработчику вообще ничего не нужно будет переделывать. Потому что сам язык моделирования и редактор диаграмм описаны декларативно. Сегодня для этих декларативных описаний генерится Java-код, заточенный под GMF. Завтра может генериться JavaScript-код, заточенный под HTML Canvas.
Ну т.е. Sirius — это тоже не про Eclipse и не про Java, а про модельно-ориентированный подход к разработке редакторов диаграмм. При котором всё по возможности описывается декларативно и потом уже генерится код, под конкретную платформу и фреймвок.
Вы упомянули в статье Rational Rose (сейчас он эволюционировал в Rational Software Architect). А для последнего используется ровно такой модельно-ориентированный подход, который я описал выше. На голом ООП в RSA и подобных инструментах это не делается. Хотя это безусловно не умоляет достоинств статьи :)
Поддерживаю, действительно, не достаточно только НЕ заниматься рутиной, лёжа на печи и смотря в потолок. Мало перестать тревожиться о «неотложных» делах и перестать сублимировать эти дела какими-то другими делами (условие 3 слоника). Ещё нужна мотивация. Я, например, черпаю мотивацию в рутине. Чем тупее и бессмысленнее работа, тем сильнее мне хочется дописать диссертацию (условие 1), появляется просто непреодолимое желание писать статьи. Я понимаю, что для диссертации нужно хотя бы 5 приличных статей, на каждую из которых нужно полгода. При этом чистого времени часов 100. Т.е. если в день я потратил на статью 1 час, то приблизился к её написанию на 1/100, а к диссертации на 1/500. Если не потратил нисколько времени, например, писал вместо статьи комментарии на хабре, то и не приблизился к цели ни на сколько. Это 2-е условие слоника.
Не важные всё это дела. Просто забудьте о них, вы не должны ничего делать. Лягте на диван и смотрите в потолок, час-два-неделю — сколько понадобится. Когда возникнет прямо нестерпимое желание, например, написать статью на хабр, то садитесь и пишите её. Если не возникнет, то лежите дальше.
А если полно каких-то «неотложных дел», которые «надо» делать, то из этой рутины никогда не выйти. 1) Вы будете бесконечно заставлять себя что-то делать. 2) Будете внутренне сопротивляться этому. 3) И вместо того чтобы делать то, что не хотите, будете делать хоть что-нибудь типа «важное» или «срочное» или, наоборот, праздное из Q4. Единственный способ выйти из этого круга — просто не делать ничего.
У меня в выходные, праздники, отпуск происходит переосмысление всего, появляются какие-то идеи, я начинаю заниматься чем-то важным и интересным. На что не хватало времени, сил, желания в рутинные будни. Надеюсь моё начальство это не прочитает :) но я стараюсь просто сознательно утром час-два забивать на работу, пока голова ещё не забита рутиной, как бы выходить из этого потока «неотложных» дел и заниматься тем, что мне интересно. Обычно эти интересные вещи через какое-то время находят применение и в работе.
Т.е. не нужно себя заставлять что-то делать. Заставьте себя на какое-то время не делать ничего и желание заняться важными вещами из Q2 появится само.
Я думаю, лучшее лекарство от прокрастинации — это ничего не делать. Если не хочется что-то делать, ну и не делайте. Но только вообще ничего включая чтение хабра, форумы, ютюб,… Люди приучены постоянно чем-то заниматься, будто у них подсознательный страх бездеятельности. Будто если они просто посидят 1 минуту, глядя в окно, то все будут их считать бездельниками. Чтобы появилось время для важных вещей, просто не делайте вообще ничего. Желание заниматься важными вещами появится само.
Я видел много людей, которые работают до ночи и даже в 2 часа ночи отвечают на рабочие звонки, работают в выходные. И ещё гордятся этим, типа посмотрите какие они работоспособные. Но в действительности основное рабочее время они тратят на перекуры, общение, а потом после окончания рабочего дня начинают срочно что-то делать. При этом на действительно важные вещи времени не остается вообще, всё время уходит на рутину. Ещё часто слышал жалобы типа: «ой, надо идти в отпуск, не чем будет заняться». Или: «сходил в отпуск, не чем было занять себя, наконец-то вышел на работу».
Блин, люди, просто не делайте ничего. На работе, дома в течение 5 минут или часа (сколько получится) просто ничем не занимайтесь. И вам в голову сразу начнут приходить гениальные мысли, вы сразу поймете, что важно, чем хотите заниматься. Представьте, что у этой обезьянки в руках два диска, которыми она постоянно стучит. И этот шум не даёт вам слышать важные вещи. Просто остановите этот шум на 5 минут.
Черновой работой будут, очевидно, заниматься мигранты. БОД, ведь планируется вводить не сразу на всей планете. Причём, если мигрантам пообещают гражданство лет через 10 усердной работы, то они с ещё большей отдачей, чем сейчас будут заниматься чем угодно.
Я обычно использовал связку SSAS + Excel. Например, для медицинского центра было всего-навсего 3 куба (поликлиника, стационар, диспансеризация) и полсотни сводных таблиц в Excel на основе этих кубов. Они покрывали процентов 90 всей отчетности. Единственное что не удобно — это смотреть в Excel на основе каких первичных данных основаны значения показателей (drill down).
Есть встроенные графические процессоры типа Intel HD Graphics. Хотя физически GPU и CPU там отдельно, но всё-равно грань размывается — один комбинированный чип. Наверное в такой архитектуре можно все числодробительные вещи вынести в GPU, а CPU упростить. Интересно, можно ли вообще всю арифметику вынести в GPU...
Кстати, а ведь раньше были FPU (математические сопроцессоры). Сначала они были отдельно, а потом их интегрировали в CPU.
C++ тоже далек от железа. Как, например, на нём сделать циклический сдвиг через флаг переноса? И как вообще работать с флагами? Всякие прикольные инструкции не поиспользуешь. Код, для которого нужны жесткие тайминги, тоже непонятно как писать. Кто его знает во что C++ код будет откомпилирован и сколько тактов это будет выполняться.
С другой стороны, для большинства задач это наверное не важно.
У нас рядом с домом детский сад, забор — сетка-рабица. Со временем в нем проковыривают проходы, потом чинят. Иногда меняют на арматуру, тогда люди перелазят через забор, но не все. У препятствий может быть разный уровень сложности, а у пешеходов разный уровень возможностей :) Одно дело взрослый человек, который может перекинуть ребенка через забор, другое — бабушка, которая идет в поликлинику. Кстати, тут возникает другая задача. Важно не только правильно проложить тропинку, но и правильно установить ворота или, наоборот, укрепления из арматуры.
Похожая проблема — парковка на газонах. Но тут наверное совершенно другие алгоритмы. Да и организовать парковку гораздо сложнее, чем асфальтировать тропинку. К тому же это легко решается автомобильными покрышками, особенно грузовыми. Которые с радостью бесплатно отдадут в любой шиномонтажке. Правда если газон большой, то приходится огораживать его покрышками постепенно. Кстати тоже интересная оптимизационная задача.
Ещё можно расширить этот алгоритм в сторону дорог, пешеходных переходов, светофоров. Например, у нас многие ходят гулять в лес и приходится преодолевать более длинный путь, чем просто через двор. С дорогами, светофорами и т.п.
По-моему из этого можно сделать не плохую игру, причём, на реальных данных! Люди будут виртуально оптимизировать дорожки и т.п., при этом нивелируя возможные недостатки алгоритма.
Сделать XML-схему, WSDL, сгенерить исходный код может школьник с незаконченным средним образованием. Это действительно очень просто.
Насчет того, что стандарты никому не нужны не могу согласиться. В конце концов, те же XML или WSDL откуда по-вашему взялись? Крупные компании создавали свои частные форматы и т.п., создавали на основе этих внутренних "стандартов" свои программные решения не совместимые с софтом других компаний. Потом собрались, обобщили свои наработки и утвердили в качестве стандарта. Стандарты везде, их полно и без них вряд ли возможна какая-то работа.
Если говорить более узко о стандартах на структуру сообщений. Ну, посмотрите где применяется ISO 20022 или модель данных всемирной таможенной организации. На последней основано энное количество более частных стандартов типа CITES, ePhyto, eTIR. Многие организации уже используют эти стандарты. Попробуйте им объяснить, что зря они их используют, есть пара студентов, которые запилят несколько XML-схем и всем будет счастье.
Описание модели eTIR — это 800 страниц текста с описанием сценариев использования, процессов, структур сообщений, согласованные с законодательством разных стран, энное количество раз вычитанные юристами и предметниками, прошедшие сотни согласований. А вы предлагаете просто запилить XML-схему и типа этого достаточно.
Для мелких организаций, да, подобные стандарты наверное не нужны. В общем-то и какой-нибудь банк топ 1 — это не очень крупная организация, которая вполне может разрабатывать свои внутренние стандарты. Но если речь идет об отраслях, межгосударственном обмене информацией, о проектах в которых количество разработчиков исчисляется тысячами, то тут только два пути: либо брать существующие стандарты, либо разрабатывать свои. Просто XML-схема не подойдет.
Ну, банально, одна подгруппа разработчиков будет описывать процессы на BPMN, а модель данных в виде ER-моделей. Другая группа будет использовать соответственно диаграммы деятельности UML и диаграммы классов. Третья будет описывать процессы словами, а модель данных будет делать сразу в виде XML-схемы и т.д. Все они будут применять разные схемы именования. Например, одни будут называть процедуры с использование глаголов в неопределенной форме, другие будут использовать отглагольные существительные, третьи будут писать как получится, но на английском языке в CamelCase. В части модели данных одни будут использовать слово товар, другие — продукт, третьи — груз для обозначения одной и той же сущности.
Для двух разработчиков, да, наверное стандарты не нужны. Но если их больше (сотни или тысячи, причём работают в разных организациях, если не разных странах), то как они обойдутся без стандартов? У одних разработчиков принято моделировать адрес как структуру, содержащую код страны, наименование города, улицы и т.п. У других принято представлять адрес в виде: строка адреса 1, строка адрес 2, строка адреса 3. Как разрешить этот противоречие? Очень просто: 1) собраться разработчикам, аналитикам и решить, что адрес будет содержать такие-то реквизиты 2) оформить это решение в виде документа и 3) утвердить в качестве стандарта.
То, что какой-то разработчик описал в XML-схеме адрес так как он захотел ничего не значит. Нужно оформить эту схему в виде документа, согласовать и утвердить.
Работницы почты в опрятной униформе, сами какие-то очень деловые. Раньше абсолютно всегда были в произвольной одежде, неспешные, недовольные. Я не знаю, что с ними произошло, но это просто небо и земля! Пока сотрудница ходила за моей посылкой, слышал как одна отчитывала другую на «Вы», мол, почему Вы опоздали, рабочий день начинается в 7:45, по новым правилам за этим строго следят. На «Вы»!
Не знаю, что у них там произошло, но для меня посещение почты сегодня утром было просто приятным шоком! Будто попал на съемки фильма или какого-то розыгрыша.
Кстати, ещё почти одновременно сделал 8 заказов на алиэкспрес с обычной доставкой (в регион, не Москва). Один пришел через 2 недели — мега-быстро! 5 заказов через 1-2 месяца. И по двум только сейчас, спустя 3 месяца пришло уведомление, что можно забрать, когда я уже отчаялся их получить. Причем, судя по трекеру, они в Москве были ещё пару месяцев назад. Что с ними происходило всё это время неизвестно. За это время их спокойно могли пару раз отправить назад и повторно отправить.
В Sirius разработчик 1) обычно берет готовое (или создает новое) декларативное описание языка моделирования в виде Ecore-модели. Эта Ecore-модель содержит описание видов сущностей, видов отношений, которые есть в языке (например, роли, варианты использования, наследование и т.п.) Для UML, BPMN и т.п. уже есть готовые Ecore-вские модели. Для своего языка моделирования такую модель сделать достаточно просто.
Затем разработчик уже с помощью непосредственно Sirius также в декларативном виде описывает как эти элементы языка моделирования должны отрисовываться, какие для них возможны действия (создание, удаление, перетаскивание). И всё. Дальше под два этих декларативных описания частично вручную, частично на лету генерится Java-код редактора диаграмм.
При этом редактор диаграмм получается внешне и функционально практически не отличим от редакторов того же Rational Software Architect, потому что последний того же основан на GMF.
В принципе, в будущем вместо GMF может использоваться какой-то другой фреймвок для отрисовки, в том числе и на основе HTML Canvas. Eclipse активно движется в этом направлении. При этом разработчику вообще ничего не нужно будет переделывать. Потому что сам язык моделирования и редактор диаграмм описаны декларативно. Сегодня для этих декларативных описаний генерится Java-код, заточенный под GMF. Завтра может генериться JavaScript-код, заточенный под HTML Canvas.
Ну т.е. Sirius — это тоже не про Eclipse и не про Java, а про модельно-ориентированный подход к разработке редакторов диаграмм. При котором всё по возможности описывается декларативно и потом уже генерится код, под конкретную платформу и фреймвок.
Вы упомянули в статье Rational Rose (сейчас он эволюционировал в Rational Software Architect). А для последнего используется ровно такой модельно-ориентированный подход, который я описал выше. На голом ООП в RSA и подобных инструментах это не делается. Хотя это безусловно не умоляет достоинств статьи :)
А если полно каких-то «неотложных дел», которые «надо» делать, то из этой рутины никогда не выйти. 1) Вы будете бесконечно заставлять себя что-то делать. 2) Будете внутренне сопротивляться этому. 3) И вместо того чтобы делать то, что не хотите, будете делать хоть что-нибудь типа «важное» или «срочное» или, наоборот, праздное из Q4. Единственный способ выйти из этого круга — просто не делать ничего.
У меня в выходные, праздники, отпуск происходит переосмысление всего, появляются какие-то идеи, я начинаю заниматься чем-то важным и интересным. На что не хватало времени, сил, желания в рутинные будни. Надеюсь моё начальство это не прочитает :) но я стараюсь просто сознательно утром час-два забивать на работу, пока голова ещё не забита рутиной, как бы выходить из этого потока «неотложных» дел и заниматься тем, что мне интересно. Обычно эти интересные вещи через какое-то время находят применение и в работе.
Т.е. не нужно себя заставлять что-то делать. Заставьте себя на какое-то время не делать ничего и желание заняться важными вещами из Q2 появится само.
Я видел много людей, которые работают до ночи и даже в 2 часа ночи отвечают на рабочие звонки, работают в выходные. И ещё гордятся этим, типа посмотрите какие они работоспособные. Но в действительности основное рабочее время они тратят на перекуры, общение, а потом после окончания рабочего дня начинают срочно что-то делать. При этом на действительно важные вещи времени не остается вообще, всё время уходит на рутину. Ещё часто слышал жалобы типа: «ой, надо идти в отпуск, не чем будет заняться». Или: «сходил в отпуск, не чем было занять себя, наконец-то вышел на работу».
Блин, люди, просто не делайте ничего. На работе, дома в течение 5 минут или часа (сколько получится) просто ничем не занимайтесь. И вам в голову сразу начнут приходить гениальные мысли, вы сразу поймете, что важно, чем хотите заниматься. Представьте, что у этой обезьянки в руках два диска, которыми она постоянно стучит. И этот шум не даёт вам слышать важные вещи. Просто остановите этот шум на 5 минут.
Кстати, а ведь раньше были FPU (математические сопроцессоры). Сначала они были отдельно, а потом их интегрировали в CPU.
С другой стороны, для большинства задач это наверное не важно.
Похожая проблема — парковка на газонах. Но тут наверное совершенно другие алгоритмы. Да и организовать парковку гораздо сложнее, чем асфальтировать тропинку. К тому же это легко решается автомобильными покрышками, особенно грузовыми. Которые с радостью бесплатно отдадут в любой шиномонтажке. Правда если газон большой, то приходится огораживать его покрышками постепенно. Кстати тоже интересная оптимизационная задача.
Ещё можно расширить этот алгоритм в сторону дорог, пешеходных переходов, светофоров. Например, у нас многие ходят гулять в лес и приходится преодолевать более длинный путь, чем просто через двор. С дорогами, светофорами и т.п.
По-моему из этого можно сделать не плохую игру, причём, на реальных данных! Люди будут виртуально оптимизировать дорожки и т.п., при этом нивелируя возможные недостатки алгоритма.
Насчет того, что стандарты никому не нужны не могу согласиться. В конце концов, те же XML или WSDL откуда по-вашему взялись? Крупные компании создавали свои частные форматы и т.п., создавали на основе этих внутренних "стандартов" свои программные решения не совместимые с софтом других компаний. Потом собрались, обобщили свои наработки и утвердили в качестве стандарта. Стандарты везде, их полно и без них вряд ли возможна какая-то работа.
Если говорить более узко о стандартах на структуру сообщений. Ну, посмотрите где применяется ISO 20022 или модель данных всемирной таможенной организации. На последней основано энное количество более частных стандартов типа CITES, ePhyto, eTIR. Многие организации уже используют эти стандарты. Попробуйте им объяснить, что зря они их используют, есть пара студентов, которые запилят несколько XML-схем и всем будет счастье.
Описание модели eTIR — это 800 страниц текста с описанием сценариев использования, процессов, структур сообщений, согласованные с законодательством разных стран, энное количество раз вычитанные юристами и предметниками, прошедшие сотни согласований. А вы предлагаете просто запилить XML-схему и типа этого достаточно.
Для мелких организаций, да, подобные стандарты наверное не нужны. В общем-то и какой-нибудь банк топ 1 — это не очень крупная организация, которая вполне может разрабатывать свои внутренние стандарты. Но если речь идет об отраслях, межгосударственном обмене информацией, о проектах в которых количество разработчиков исчисляется тысячами, то тут только два пути: либо брать существующие стандарты, либо разрабатывать свои. Просто XML-схема не подойдет.
Ну, банально, одна подгруппа разработчиков будет описывать процессы на BPMN, а модель данных в виде ER-моделей. Другая группа будет использовать соответственно диаграммы деятельности UML и диаграммы классов. Третья будет описывать процессы словами, а модель данных будет делать сразу в виде XML-схемы и т.д. Все они будут применять разные схемы именования. Например, одни будут называть процедуры с использование глаголов в неопределенной форме, другие будут использовать отглагольные существительные, третьи будут писать как получится, но на английском языке в CamelCase. В части модели данных одни будут использовать слово товар, другие — продукт, третьи — груз для обозначения одной и той же сущности.
Для двух разработчиков, да, наверное стандарты не нужны. Но если их больше (сотни или тысячи, причём работают в разных организациях, если не разных странах), то как они обойдутся без стандартов? У одних разработчиков принято моделировать адрес как структуру, содержащую код страны, наименование города, улицы и т.п. У других принято представлять адрес в виде: строка адреса 1, строка адрес 2, строка адреса 3. Как разрешить этот противоречие? Очень просто: 1) собраться разработчикам, аналитикам и решить, что адрес будет содержать такие-то реквизиты 2) оформить это решение в виде документа и 3) утвердить в качестве стандарта.
То, что какой-то разработчик описал в XML-схеме адрес так как он захотел ничего не значит. Нужно оформить эту схему в виде документа, согласовать и утвердить.