Delphi for zOS

[Kolbasoff]

[Так что учиться надо постоянно, вопрос нравится учиться или в напряг. Мне лично нравится. И в добавок, чем больше знаешь, тем приятнее коллектив.

Я тоже люблю учиться, но как-то стало влом изучать то, что завтра станет мусором. Хоцца чего-то более фундаментального.

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

[Komissar]

[Так что учиться надо постоянно, вопрос нравится учиться или в напряг. Мне лично нравится. И в добавок, чем больше знаешь, тем приятнее коллектив.

Я тоже люблю учиться, но как-то стало влом изучать то, что завтра станет мусором. Хоцца чего-то более фундаментального.

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

Не знаю, изучать пургу чужих неокрепших мозгов, которую уже завтра заметет новым снежком...

[Kolbasoff]

Не знаю, изучать пургу чужих неокрепших мозгов, которую уже завтра заметет новым снежком...

Ну я согласен, я бы с удовольствием занимался приматкой и аккумулировал бы опыт. Но в приматку меня не пускают (а я просился), но я не теряю задора и не торопясь но поспешая подкрадываюсь к ней с тыла.

[Easbayguy]

[Так что учиться надо постоянно, вопрос нравится учиться или в напряг. Мне лично нравится. И в добавок, чем больше знаешь, тем приятнее коллектив.

Я тоже люблю учиться, но как-то стало влом изучать то, что завтра станет мусором. Хоцца чего-то более фундаментального.

Прошли те года когда коммисары хотели стать к станку и кодировать потихоньку!

[Komissar]

[Так что учиться надо постоянно, вопрос нравится учиться или в напряг. Мне лично нравится. И в добавок, чем больше знаешь, тем приятнее коллектив.

Я тоже люблю учиться, но как-то стало влом изучать то, что завтра станет мусором. Хоцца чего-то более фундаментального.

Прошли те года когда коммисары хотели стать к станку и кодировать потихоньку!

да, то был юношеский пыл... уже угас

[stenking]

Ну так а вы не убер экосистемы у js то как раз и нет. и вообще это можно сказать на коленке, наспех сляпаный язык, которым пользуются чисто по случайности. программисты под него сейчас дорогие, фреймворков нет нормальных, писать на нем тяжелее чем на шарпе (для бэкенда), в чем плюс я не понял.
Проект у меня довольно мелкий, но уже нод не подходит и не вытягивает. просто по факту - надо из терминала по dde забирать котировки, обрабатывать на linq, потом отдавать на sql и по спец. логике мержить и кешировать. я не замерял, но уверен что js куда хуже обрабатывает гигабайтные массивы данных в реальном времени. По Ms sql тоже не понял где хранить мои 300 гб данных, кроме как там. в общем ни по одному пункту нод не подходит

кстати у меня именно singlepage, в чем проблемы я так и не понял

У вас совсем не синглпейдж. У вас классический г-код jQuery который никто никогда кроме вас не поймёт. Притом все 10К строчек в одном файле с onclick... Про не вытягивает нод - смешно. У аирбнб вытягивает, у Убера вытягивает а ваших пару гигов нет, ага.

А правильный сингпейдж это абсолютно другой подход. Это докер, это CI, это фронтэнд тесты, это хороший билд который минифицирует, версионирует, спрайтифицирует, это хорошо построенный процесс ( задача => шаги => PR => code review => merge...), это стейжинг с автоапдейтом, это инеграция с системой локализации и общий дикшионари с лейблами ну и конечно же клиент который состоит из тысяч файлов со сложной логикой.

А если эпп работает офлайн, автоапдейтит все и ещё с него можно сделать гибридный билд на iOS/Android с автоапдейтом то вообще 5-ка. Да, в 2017 нужно делать именно такие эппы а не тянуть г-но из прошлого.

[ALV00]

каким боком json к map-reduce ? вы нахватались базвордов но, что стоит за словом не понимаете.
key-vale и нолики и единички в 60х тоже использовали, но это не повод натягивать сову на глобус. суть map-reduce в разбивке задачи на независимые куски, которые можно обсчитывать в параллель. в 60х-70х параллельно даже перфокарты воткнуть не догадывались.

NoSQL и MapReduce это как бы разные вещи. MR может быть в NoSQL базе, а может и не быть. С другой стороны можно SQL базу реализовать на MR. То что характеризует NoSQL это отсутствие реляционности. Что похоже на иерархические базы данных, деланные еще при царе Горохе. Что я и хотел сказать: новое это хорошо забытое старое.

[OtherSide]

Ну так а вы не убер экосистемы у js то как раз и нет. и вообще это можно сказать на коленке, наспех сляпаный язык, которым пользуются чисто по случайности. программисты под него сейчас дорогие, фреймворков нет нормальных, писать на нем тяжелее чем на шарпе (для бэкенда), в чем плюс я не понял.
Проект у меня довольно мелкий, но уже нод не подходит и не вытягивает. просто по факту - надо из терминала по dde забирать котировки, обрабатывать на linq, потом отдавать на sql и по спец. логике мержить и кешировать. я не замерял, но уверен что js куда хуже обрабатывает гигабайтные массивы данных в реальном времени. По Ms sql тоже не понял где хранить мои 300 гб данных, кроме как там. в общем ни по одному пункту нод не подходит

кстати у меня именно singlepage, в чем проблемы я так и не понял

У вас совсем не синглпейдж. У вас классический г-код jQuery который никто никогда кроме вас не поймёт. Притом все 10К строчек в одном файле с onclick... Про не вытягивает нод - смешно. У аирбнб вытягивает, у Убера вытягивает а ваших пару гигов нет, ага.

А правильный сингпейдж это абсолютно другой подход. Это докер, это CI, это фронтэнд тесты, это хороший билд который минифицирует, версионирует, спрайтифицирует, это хорошо построенный процесс ( задача => шаги => PR => code review => merge...), это стейжинг с автоапдейтом, это инеграция с системой локализации и общий дикшионари с лейблами ну и конечно же клиент который состоит из тысяч файлов со сложной логикой.

А если эпп работает офлайн, автоапдейтит все и ещё с него можно сделать гибридный билд на iOS/Android с автоапдейтом то вообще 5-ка. Да, в 2017 нужно делать именно такие эппы а не тянуть г-но из прошлого.

Так Вы похоже не знаете что такое singlepage. На самом деле это такая структура сайта, когда страница целиком никогда не обновляется, а обновляются только ее части. Никакого отношения к говнокоду и хорошо построенным процессам это не иммет.
У меня сайт именно такой, по крайней мере мобильная версия - точно. https://ru-ticker.com/Mobile" onclick="window.open(this.href);return false;
Кстати, есть сборка и под Andoroid, под ios правда не собрал еще, т.к. мак для сборок только недавно купил. jQuery у меня кстати нет практически - зачем он там, если основное - это рисование по canvas.

Пенять процессами - идиотизм. Какие могут быть процессы, если в команде полтора человека. Я что, сам себе буду документацию по задаче писать и тикеты на тестирование выдаывать?

Убер упоминать тоже идиотизм. Причем тут он? Тем более еще вчера писали, что я не Убер. Тем более был задан вполне конкретный вопрос - как организовать межпроцессное взаимодействие и импорт под DDE на js. К тому же уверен, что в Убере на js на сервере используется только что бы данные отдавать ангуляру на фронтенд. Никогда не поверю, что картографический сервис написан на скриптовом языке. Скорее всего арендуют у гугла, а там что то вроде чистых плюсов.

[iDesperado]

NoSQL и MapReduce это как бы разные вещи. MR может быть в NoSQL базе, а может и не быть. С другой стороны можно SQL базу реализовать на MR. То что характеризует NoSQL это отсутствие реляционности. Что похоже на иерархические базы данных, деланные еще при царе Горохе. Что я и хотел сказать: новое это хорошо забытое старое.

вы глупость хотите сказать, еще раз ничего похожего на map-reduce в 60х,70х не было. вы судорожно сейчас пытаетесь почитать о действительно новых подходах, вместо того что бы признать, что ляпнули не подумав.
SQL можно реализовать на MR, можно по иерархической субд пускать, SQL можно и без субд на ряду с лямдами spark использовать. у вас полная каша в понятиях.

[Boriskin]

Самому не смешно? Такие вот дурачки инвесторы, дурачки пользователи, дурачки покупатели и хитрые стартаперы которые всех дурят раздувая хайп

На примере фейсбука это хорошо заметно.
Продукт - ведь полное гавно. Создан в качестве паллиатива социальной деятельности и по сути - монетизация чувства неполноценности пишущих туда индивидов.

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

[Boriskin]

Тот курс что преподавали был настолько нашпигован теорией что его сдать было не легче чем, к примеру, курс функана или теории групп.

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

[fruit6]

Тоже самое что и ТВ, только 'через интернет'.

[sp123]

NoSQL и MapReduce это как бы разные вещи. MR может быть в NoSQL базе, а может и не быть. С другой стороны можно SQL базу реализовать на MR. То что характеризует NoSQL это отсутствие реляционности. Что похоже на иерархические базы данных, деланные еще при царе Горохе. Что я и хотел сказать: новое это хорошо забытое старое.

вы глупость хотите сказать, еще раз ничего похожего на map-reduce в 60х,70х не было. вы судорожно сейчас пытаетесь почитать о действительно новых подходах, вместо того что бы признать, что ляпнули не подумав.
SQL можно реализовать на MR, можно по иерархической субд пускать, SQL можно и без субд на ряду с лямдами spark использовать. у вас полная каша в понятиях.

А вот возьму и поддержу ALV00! Именно так, привет из 70-х, ощущения один в один. Key-value с одним индекcом на строку и мусорным текстом внутри, в лучшем случае json. Теория баз данных, 21 век, my ass. А, ну да, есть еще модные штуки типа ORC и Parquet, совсем недавно появились, просто праздник какой-то. И еще пара-тройка SQL интерфейсов, запустил и иди пить кофе, ну или наблюдай пародию на execution plan в замедленной съемке. Единственное, что реально впечатляет во всем этом зоопарке - параллельная обработка и репликация. Все. MR - ваще атас, простейший алгоритм файловой дробилки в два прохода, а понтов-то. На ЧМК тетки в 70-х на EC зарплату на десятки тысяч человек считали на ассемблере в 36K памяти аппаратно-зависимо, вот это я понимаю высший пилотаж! zVlad не даст соврать.

[iDesperado]

А вот возьму и поддержу ALV00! Именно так, привет из 70-х, ощущения один в один. Key-value с одним индекcом на строку и мусорным текстом внутри, в лучшем случае json. Теория баз данных, 21 век, my ass. А, ну да, есть еще модные штуки типа ORC и Parquet, совсем недавно появились, просто праздник какой-то. И еще пара-тройка SQL интерфейсов, запустил и иди пить кофе, ну или наблюдай пародию на execution plan в замедленной съемке. Единственное, что реально впечатляет во всем этом зоопарке - параллельная обработка и репликация. Все. MR - ваще атас, простейший алгоритм файловой дробилки в два прохода, а понтов-то. На ЧМК тетки в 70-х на EC зарплату на десятки тысяч человек считали на ассемблере в 36K памяти аппаратно-зависимо, вот это я понимаю высший пилотаж! zVlad не даст соврать.

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

[Easbayguy]

А вот возьму и поддержу ALV00! Именно так, привет из 70-х, ощущения один в один. Key-value с одним индекcом на строку и мусорным текстом внутри, в лучшем случае json. Теория баз данных, 21 век, my ass. А, ну да, есть еще модные штуки типа ORC и Parquet, совсем недавно появились, просто праздник какой-то. И еще пара-тройка SQL интерфейсов, запустил и иди пить кофе, ну или наблюдай пародию на execution plan в замедленной съемке. Единственное, что реально впечатляет во всем этом зоопарке - параллельная обработка и репликация. Все. MR - ваще атас, простейший алгоритм файловой дробилки в два прохода, а понтов-то. На ЧМК тетки в 70-х на EC зарплату на десятки тысяч человек считали на ассемблере в 36K памяти аппаратно-зависимо, вот это я понимаю высший пилотаж! zVlad не даст соврать.

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

Всего навсего два процесса:
1) Стоимость разработчиков увеличилась значительно.
2) Стоимость железа/памяти/ССД упала по самое немогу.

[Мальчик-Одуванчик]

Тот курс что преподавали был настолько нашпигован теорией что его сдать было не легче чем, к примеру, курс функана или теории групп.

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

Малышкин вел? Эт здорово что было на чем проверить полученные знания.

[zVlad]

..... На ЧМК тетки в 70-х на EC зарплату на десятки тысяч человек считали на ассемблере в 36K памяти аппаратно-зависимо, вот это я понимаю высший пилотаж! zVlad не даст соврать.

Да на ассемблере, да на ~30000 человек, добавлю: весьма заковыристую зарплату, сейчас она попроще наверное будет, и да, довольно простые, в годах женщины, разрабатывали, писали блок-схемы, код, тестировали отлаживали и доводили до результата: ведомостей выдачи зарплат и квитки (за что как начисленно, что удержано).
Но не на 36К, больше, когда я пришел в ЧМК, там была ЕС-1061 с 4М памяти, а до того была пара ЕС-1033 и минимум 512К, две штуки было вроде. Что значит аппаратно-зависимой?

[Мальчик-Одуванчик]

Мне как раз довелось застать альтернативное движение, когда вместо ЕС массово пошли машины серии СМ-1420 и Mera-(2?)
Их как раз начали внедрять в небольшие предприятия с численностью рабочих не больше нескольких тысяч как раз для полной бухгалтерии, склада, продаж ну и расчета зарплаты, само-собой. Эти ЭВМ так же использовались для автоматизации производств (автоматизированный склад, инструменталка, хранилище программ для станков с ЧПУ), но в последнем случае они работали совместно с промышленными контроллерами (Электроника-60?) или СМ-1800, которая уже была на Ителовском процессоре и шине (и еще язык свой PL/M).

[iDesperado]

Всего навсего два процесса:
1) Стоимость разработчиков увеличилась значительно.
2) Стоимость железа/памяти/ССД упала по самое немогу.

да не в этом дело. в современных rdbms большой груз за плечами, а на самом деле много задач всей той фигни, которой славен тот же оракл не нужно. целому пласту задач не нужны блокировки в оракловом блоке, не нужна консистетность и SCN в блоке, много чего не нужно. в результате в оракл табличка 20Gb, в parquet она же 1.8Gb
зато там другое порно. как минимум, не менее задорное, чем оракл. но суть не в этом, суть в ом что в 70х не было нихрена похожего. не-бы-ло. и трава нифига не зеленее.

p.s. я на теток с ЕС ЭВМ насмотрелся. две штуки. 15 лет опыта у каждой, просили пристроить. я не смог. 15 лет опыта, ни одна не смогла освоить norton и хотя бы запустить foxpro. 15 лет они приходили на завод, наливали чай ...
обе клуши метут полы.

[zVlad]

Мне как раз довелось застать альтернативное движение, когда вместо ЕС массово пошли машины серии СМ-1420 и Mera-(2?) ....

Никогда СМ не шли вместо ЕС. ЕС шли в свою нишу н/х, СМ в свою. Были предприятия где было и то и другое. Никто даже не думал о замене одних другими.
На ЧМК у нас были СМ для подготовки данных на магнитных лентах, которые потом шли на ЕС-ки. В 90-годы эту подготовку данных мы заменили прямым вводам на МФ (на тот момент у нас уже были ИБМ МФ: две машины с 32М и по два процессора на каждом. 20 Гб дисков. Это 1993 год.

[Мальчик-Одуванчик]

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

А по-моему была в 70-х годах система ADABAS, которая достаточно похожа на это новомодное порно. В CCCP тоже с успехом эксплуатировалась.

[Мальчик-Одуванчик]

Никогда СМ не шли вместо ЕС. ЕС шли в свою нишу н/х, СМ в свою. Были предприятия где было и то и другое. Никто даже не думал о замене одних другими.

На Дальнем Востоке ЕС, похоже вообще с какого то времени перестали закупать. На крупные предприятия типа вертолетного завода завозили СМ для всех типов задач. Они были менее прихотливы, особенно в отношении вибрации, загрязненности и размера.
Если для СМ1420 еще требовалось отдельное помещение с фальшполом и парочка уже обычных бытовых кондиционеров, то Меры или CМ1800 ставили прямо в цеху, лишь огораживая от лишней пыли участок за стеклянной стойкой. Возможно и стоили они существенно дешевле (золота там было точно на порядок меньше). Наш ящик как раз и занимался обслуживанием всего этого зоопарка и машин серии ЕС на весь край было очень мало - не больше десятка, а СМ гораздо больше. Причем все ЕС территориально находились лишь в краевом центре, в то время как СМ - в каждом городе. Еще была ЕС на научнике, но я как раз застал момент её списания и замену на СМ.

[iDesperado]

А по-моему была в 70-х годах система ADABAS, которая достаточно похожа на это новомодное порно. В CCCP тоже с успехом эксплуатировалась.

ничем оно не похоже. примитив, который как и все в 70х танцевал от структуры, без каких либо попыток разложить запрос и читать в параллель.

[Easbayguy]

А по-моему была в 70-х годах система ADABAS, которая достаточно похожа на это новомодное порно. В CCCP тоже с успехом эксплуатировалась.

ничем оно не похоже. примитив, который как и все в 70х танцевал от структуры, без каких либо попыток разложить запрос и читать в параллель.

Какaя в попу тогда параллель, с 29 мегабайтными дисками которые были как ведро!

[zVlad]

Никогда СМ не шли вместо ЕС. ЕС шли в свою нишу н/х, СМ в свою. Были предприятия где было и то и другое. Никто даже не думал о замене одних другими.

На Дальнем Востоке ЕС, похоже вообще с какого то времени перестали закупать. На крупные предприятия типа вертолетного завода завозили СМ для всех типов задач. Они были менее прихотливы, особенно в отношении вибрации, загрязненности и размера.
.......

ЕС ЭВМ делались (для военных) в мобильном варианте, на автобазе Урал, а также ставились на подводные лодки. Были и ОС собственного изготавления, не ИБМ ОС.