Выглядит конечно круто, но тут больше идет про АТМ совместимые компьютеры, чем Spectrum совместимые. В свое время конечно ATM Turbo для меня была мечта и машинка выглядела супер круто. А сейчас я понимаю что настоящая Spectrum OS должна иметь возможность как то запуститься на оригинальном 128 килобайтной машине, а то и 48. Возможно с дополнительной периферией, подключаемой через порт расширения, туда можно как раз и дополнительную память впихнуть, и контроллеры SSD, а то и видеокарту с поддержкой расширенных режимов, цветов, аппаратным скроллингом, а то и вообще поддержкой 3D. А для NedoOS ИМХО имеет смысл еще сделать чтобы она и на Amstrad CPC могла запуститься, было бы круто если бы была возможность за счет OS объединить 2 платформы.
Эххх, ностальгия :). Вспоминаю ситуацию, когда я купил дискету с софтом и сдуру грохнул нулевой сектор, где была вся файловая система. Что смешно — смог все полностью восстановить :). А кассетных версий в свое время на дискеты довольно много адаптировал. Называется — было время, когда разработчик практически полностью понимал как это все работает :). С другой стороны — после всего этого пришлось практически полностью переучиваться чтоб избавиться от стремления оптимизировать все и вся и экономить каждый байт путем запутывания кода :).
А отличник — это кто такой? У кого отличные знания и умения или у кого пятерки одни? Чаще всего это совершенно разные вещи. Оценка 5 по объективной шкале может быть вообще нулем, ибо поставлена автоматом за былые заслуги. Двойка может быть за то, что твою лабу сдал раздолбай 1 в 1. Или за то, что задал вопрос преподавателю. Или за то, что предмет знал лучше препода и не ходил, а тот оценки ставил за посещаемость в основном. Отличники бывают очень и очень разные вообще то.
Лично я был и отличником, и троечником. Отличником был в школе. Вкалывал ради медали. Ибо в мое время медаль давала льготы при поступлении, для поступлении было достаточно сдать математику на пять. А сочинение на месте на пять я бы не написал. В институте мне на оценки было плевать. Но на знания было не плевать, потому для меня 5 с половиной лет не были совсем уж впустую потраченным временем именно в учебном плане.
Даже без поддержки. Если писать в спагетти стиле — количество багов будет такое, что релиз будет лет через 10. И количество тестировщиков должно быть неимоверное. Хотя, возможно я конкретно к этому проекту несправедлив. В другом проекте навскидку все вполне нормально выглядит, естественно я не вникал, но навскидку ничего криминального, за сердце не хватаешься. А этот проект просто тупо переписывали как есть с одного языка на другой. Основной критерий — чтоб оно скомпилировалось и заработало также, как и ранее. Заработало хоть как то, отдали и забили :).
А хотел :)? Ты начальству скажи — сделает. При желании сделает, даже если ты работаешь программистом только полгода, у тебя эта первая работа и по образованию ты учитель физкультуры :). Только не факт что тебе эта административщина сильно понравится. Как разработчик ты достаточно хорошо удален скорее всего от бюрократии, даже если контора там СММ5, тебе пофиг. А начнешь тимлидить — будешь только и заниматься тем, что смотреть за JIRA, какие то отчеты о работе команды за итерацию писать, а также другой хренью бюрократической. Одни совещания, причем в основном из пустого в порожнее переливают. В код уже не смотришь. Степень маразмов бюрократии начнет ужасать. Проблемы вообще не технические, а административные в основном — нет ТЗ, хотят абсолютно невозможное, постоянно меняют требования и хотят все еще вчера. Хорошо если тимлидом стал из юниора. Но если достиг какого то уровня, то видишь, что все твои технические навыки нахрен не нужны, а нужны совершенно другие, которых у тебя пока нет. И самое неприятное, удовольствия от такой работы не получаешь, а также видишь, что твои технические скилы достаточно быстро деградируют. Сам уже за подчиненных через 3 года фиг что сделать сможешь.
А какие проблемы? Тим лид в большинстве контор даже код не пишет. Основные задачи там — разобраться со спекой, поставить задачи чтоб было понятно что требуется, следить за выполнением и т.д. Разрешение конфликтов и т.д. То есть сугубо административная работа. Чаще всего в тимлиды берут тех, у кого лучше подвешен язык. Если брать буржуйских заказчиков, то тех, у кого лучше английский.
Если тимлид был сам в прошлом неплохим прогрвммистом — это может быть как плюсом, так и минусом. Плюс, так как ему проще объяснить. Минус — он может начать заниматься микроменеджментом, а навыки программирования у него деградируют со временем и он может продавливать фиговые решения.
О, госсподи, давно я такого не видел к своему счастью. Так это типичный юниорский код. Code Review не проводится. При наборе спрашивают типичные вопросы, одинаковые и для юниоров и для сеньеров, единственное отличие что сеньер не имеет право "неправильно" отвечать. При собеседованиях умение нормально делать декомпозиции задач на подзадачи крайне редко кто проверяет. Отсюда и код, подобного которому я к счастью очень давно не видел :). Но у этого кода есть один плюс. Для его поддержки требуется больше народа. Если больше народа, больше денег получится выдоить с заказчика и следовательно больше прибыль получит контора. И потом можно будет еще раз контрактик взять на переписывание такой лапши, якобы ради миграции на какую новую модную технологию.
Можно спросить, как мне скопипастить? Только что я поставил MPS 2017.1.2. У меня при старте открылся класс Main с тестовым примером. Я мечтаю его текст вставить сюда. И я не могу даже выделение сделать. Единственное что я смог сделать — это нажать preview generated text, но это не совсем то, что мне хочется.
Мне вот одно интересно, я один считаю, что MPS в текущем виде пользоваться практически невозможно? Ибо текст программы по существу графический, хоть и выглядит текстовым. Банально невозможно скопипастить текст чтоб спросить на форуме. Даже в этой статье в качестве примеров идут картинки, хотя Java класс Temperature идет текстом.
Странно. Я вообще начинал с венгерки. Думал что она прекрасна, позволяет избежать ошибок и т.д. Потом пересел на Java, поработал в нормальных IDE, и для меня необходимость в венгерке отпала. А после того, как пописал на языках, где есть функционал val (или auto), то есть тип слева от переменной можно не указывать, почему то пришло понимание, что это тоже очень хорошо. Пришло понимание, что нужно думать об имени переменной, а не о типе, о типе должен компилятор, а не я, постоянно помнить. В результате гораздо стало проще рефакторить а также гораздо проще читать код. Ошибаться стал меньше, чем когда венгерку использовал.
Учитывая, что сейчас я в имени никакую информацию о типах стараюсь не давать, а то и вообще типы явно не указываю, то следует ли считать, что лет 15 назад я был лучшим разработчиком, чем сейчас :)? Я ведь тогда многое что делал дополнительно, еще и когда скобочку закрывал, я в комментах писал к чему эта скобочка относится и тому подобное. А сейчас забил на это, и просто делаю методы короткими, а имена максимально понятными.
Никто не говорит, что на Java нельзя написать DSLи. Можно и нужно, и эти DSL могут быть вполне годные с точки зрения декларативности и компактности, если не нужны будут арифметические операции. Но все равно выглядит это как костыль. Двойные скобочки, ._(); оператор new и не следование конвенции что имя класса должно быть с большой буквы, передача this в параметры — это мусор, от которого не удалось избавиться.
Конечно намного лучше, чем без DSL вообще. Но на anko это смотрится органично и изящно, там сам язык оптимизирован под такие DSL.
По графике конечно красиво. Интересно, как аэродинамику делаете? Просто математическая модель, или снимаете реальные данные с реального самолета, на основе этого делая обучение? Критические режимы рассматриваете, насколько хорошо эмулируются? А закритические? Насколько хорошо умеете движение воздушных масс эмулировать (хотя без подвижной платформы там мало толку будет)? Контроллеры у вас свои, или просто симмерские без обратной связи?
ceph… Ты как то тоже рассматривали как делать персистентность и ceph рассматривали. Не понравилось, что там должна обязательно быть главная нода. Я тогда думал выбрать glusterFs, но админы сказали что не факт что будет стабильно работать. В итоге сейчас админы настроили torrentSync между нодами, вроде для наших целей пока подходит.
1500 pod и 50 нод — не такие уж и маленькие проекты вообще то.
Кстати, а как персистентность и базы разруливаете? В качестве распределенного файлового хранилища что используете, nfs (как на слайде)?
Базы живут у вас где, внутри kubernetes (в одном экземпляре, с маппингом на хостовую файловую систему, часть нод помечены как соделжащие базы), или же во внешнем окружении есть отдельный кластер или просто отдельная машина.
Можно попробовать использовать обычный map. Вернется условно Seq[Object]. И далее можно этот Seq[Object] преобразовать снова к Tuple уже конкретных типов. Но к сожалению тип не получится вывести автоматом, мне придется делать что то ручного каста.
Я понял. Скорее всего для кортежей скорее всего можно извратиться. Но костылище будет еще то, не факт что будет иметь смысл такие извращения.
Отдельный метод, принимающий кортеж, у которого обязательства вернуть кортеж строго с такими же типами. Внутри обработчик, принимающий union type, обрабатывающий типы и инкрементящий. И при возврате проверка, что тип кортежа не изменился.
В Ceylon нет многого из того, что есть в Scala. В Kotlin аналогично :).
Немножко громоздко, но можно привыкнуть. Я правильно понимаю, что вот для такого понадобятся дополнительные скобки?
Вот для такого на самом деле в текущей версии языка придется делать кое что покруче чем скобки:
value res = {for (x in (1..15).by(2))
for (z in {x * x - 1})
if (z % 3 == 0)
for (y in (1..10).by(3))
z->y};
То есть для z пришлось имитировать итерированием по последовательности из одного элемента. В будущем обещают let разрешить внутри for comprehensions, пока так.
Future по идее можно привести к коллекции из одного элемента. Примерно таким же способом, как я с z извратился.
async await планируют в будущем, но не знаю сколько лет еще ждать. Я пока вместо asinc await просто rxJava использую. Плюс у меня есть библиотечный async метод, который стартует Java поток. Возвращающий Observable. Соответственно внутри потока могу стартовать еще с помощью async другие потоки, и далее у Observable вызываю blockingFirst. Пока не появится async await в языке — живу вот так.
24
На самом деле Ceylon достаточно неплохо работает с Java коллекциями и в принчипе взаимодействие для программиста незаметное. Правда пока можно нарваться на багу взаимодействия с Java, в результате чего может не скомпилиться и придется искать обходные пути, фича новая и не все крайние условия пойманы. Касается баги в основном преобразования цейлоновских лямбд в Java лямбды — часто это работает, а если не работает приходится по старинке генерировать анонимный класс что громоздко.
Лично я был и отличником, и троечником. Отличником был в школе. Вкалывал ради медали. Ибо в мое время медаль давала льготы при поступлении, для поступлении было достаточно сдать математику на пять. А сочинение на месте на пять я бы не написал. В институте мне на оценки было плевать. Но на знания было не плевать, потому для меня 5 с половиной лет не были совсем уж впустую потраченным временем именно в учебном плане.
Даже без поддержки. Если писать в спагетти стиле — количество багов будет такое, что релиз будет лет через 10. И количество тестировщиков должно быть неимоверное. Хотя, возможно я конкретно к этому проекту несправедлив. В другом проекте навскидку все вполне нормально выглядит, естественно я не вникал, но навскидку ничего криминального, за сердце не хватаешься. А этот проект просто тупо переписывали как есть с одного языка на другой. Основной критерий — чтоб оно скомпилировалось и заработало также, как и ранее. Заработало хоть как то, отдали и забили :).
А хотел :)? Ты начальству скажи — сделает. При желании сделает, даже если ты работаешь программистом только полгода, у тебя эта первая работа и по образованию ты учитель физкультуры :). Только не факт что тебе эта административщина сильно понравится. Как разработчик ты достаточно хорошо удален скорее всего от бюрократии, даже если контора там СММ5, тебе пофиг. А начнешь тимлидить — будешь только и заниматься тем, что смотреть за JIRA, какие то отчеты о работе команды за итерацию писать, а также другой хренью бюрократической. Одни совещания, причем в основном из пустого в порожнее переливают. В код уже не смотришь. Степень маразмов бюрократии начнет ужасать. Проблемы вообще не технические, а административные в основном — нет ТЗ, хотят абсолютно невозможное, постоянно меняют требования и хотят все еще вчера. Хорошо если тимлидом стал из юниора. Но если достиг какого то уровня, то видишь, что все твои технические навыки нахрен не нужны, а нужны совершенно другие, которых у тебя пока нет. И самое неприятное, удовольствия от такой работы не получаешь, а также видишь, что твои технические скилы достаточно быстро деградируют. Сам уже за подчиненных через 3 года фиг что сделать сможешь.
А какие проблемы? Тим лид в большинстве контор даже код не пишет. Основные задачи там — разобраться со спекой, поставить задачи чтоб было понятно что требуется, следить за выполнением и т.д. Разрешение конфликтов и т.д. То есть сугубо административная работа. Чаще всего в тимлиды берут тех, у кого лучше подвешен язык. Если брать буржуйских заказчиков, то тех, у кого лучше английский.
Если тимлид был сам в прошлом неплохим прогрвммистом — это может быть как плюсом, так и минусом. Плюс, так как ему проще объяснить. Минус — он может начать заниматься микроменеджментом, а навыки программирования у него деградируют со временем и он может продавливать фиговые решения.
О, госсподи, давно я такого не видел к своему счастью. Так это типичный юниорский код. Code Review не проводится. При наборе спрашивают типичные вопросы, одинаковые и для юниоров и для сеньеров, единственное отличие что сеньер не имеет право "неправильно" отвечать. При собеседованиях умение нормально делать декомпозиции задач на подзадачи крайне редко кто проверяет. Отсюда и код, подобного которому я к счастью очень давно не видел :). Но у этого кода есть один плюс. Для его поддержки требуется больше народа. Если больше народа, больше денег получится выдоить с заказчика и следовательно больше прибыль получит контора. И потом можно будет еще раз контрактик взять на переписывание такой лапши, якобы ради миграции на какую новую модную технологию.
Да ужжж. Конечно радует, что это можно сделать. Но очень не интуитивно, без подсказки я б точно не догадался. А мышкой это никак нельзя сделать?
Можно спросить, как мне скопипастить? Только что я поставил MPS 2017.1.2. У меня при старте открылся класс Main с тестовым примером. Я мечтаю его текст вставить сюда. И я не могу даже выделение сделать. Единственное что я смог сделать — это нажать preview generated text, но это не совсем то, что мне хочется.
Мне вот одно интересно, я один считаю, что MPS в текущем виде пользоваться практически невозможно? Ибо текст программы по существу графический, хоть и выглядит текстовым. Банально невозможно скопипастить текст чтоб спросить на форуме. Даже в этой статье в качестве примеров идут картинки, хотя Java класс Temperature идет текстом.
Странно. Я вообще начинал с венгерки. Думал что она прекрасна, позволяет избежать ошибок и т.д. Потом пересел на Java, поработал в нормальных IDE, и для меня необходимость в венгерке отпала. А после того, как пописал на языках, где есть функционал val (или auto), то есть тип слева от переменной можно не указывать, почему то пришло понимание, что это тоже очень хорошо. Пришло понимание, что нужно думать об имени переменной, а не о типе, о типе должен компилятор, а не я, постоянно помнить. В результате гораздо стало проще рефакторить а также гораздо проще читать код. Ошибаться стал меньше, чем когда венгерку использовал.
Учитывая, что сейчас я в имени никакую информацию о типах стараюсь не давать, а то и вообще типы явно не указываю, то следует ли считать, что лет 15 назад я был лучшим разработчиком, чем сейчас :)? Я ведь тогда многое что делал дополнительно, еще и когда скобочку закрывал, я в комментах писал к чему эта скобочка относится и тому подобное. А сейчас забил на это, и просто делаю методы короткими, а имена максимально понятными.
Никто не говорит, что на Java нельзя написать DSLи. Можно и нужно, и эти DSL могут быть вполне годные с точки зрения декларативности и компактности, если не нужны будут арифметические операции. Но все равно выглядит это как костыль. Двойные скобочки, ._(); оператор new и не следование конвенции что имя класса должно быть с большой буквы, передача this в параметры — это мусор, от которого не удалось избавиться.
Конечно намного лучше, чем без DSL вообще. Но на anko это смотрится органично и изящно, там сам язык оптимизирован под такие DSL.
По графике конечно красиво. Интересно, как аэродинамику делаете? Просто математическая модель, или снимаете реальные данные с реального самолета, на основе этого делая обучение? Критические режимы рассматриваете, насколько хорошо эмулируются? А закритические? Насколько хорошо умеете движение воздушных масс эмулировать (хотя без подвижной платформы там мало толку будет)? Контроллеры у вас свои, или просто симмерские без обратной связи?
1) Есть еще деструктуризация Entry, то есть пар ключ значение
2) Виноват, ошибся, имел в виду перегрузку методов или функций
Связано просто, пишем:
Вместо
ceph… Ты как то тоже рассматривали как делать персистентность и ceph рассматривали. Не понравилось, что там должна обязательно быть главная нода. Я тогда думал выбрать glusterFs, но админы сказали что не факт что будет стабильно работать. В итоге сейчас админы настроили torrentSync между нодами, вроде для наших целей пока подходит.
1500 pod и 50 нод — не такие уж и маленькие проекты вообще то.
Кстати, а как персистентность и базы разруливаете? В качестве распределенного файлового хранилища что используете, nfs (как на слайде)?
Базы живут у вас где, внутри kubernetes (в одном экземпляре, с маппингом на хостовую файловую систему, часть нод помечены как соделжащие базы), или же во внешнем окружении есть отдельный кластер или просто отдельная машина.
Во первых, case class и data class как раз и нету :). Типа String|String быть не может — он сворачивается просто в String
Осуществить подобное....
Можно попробовать использовать обычный map. Вернется условно Seq[Object]. И далее можно этот Seq[Object] преобразовать снова к Tuple уже конкретных типов. Но к сожалению тип не получится вывести автоматом, мне придется делать что то ручного каста.
Но вообще, фича запланирована:
https://github.com/ceylon/ceylon/issues/5838
Так что рано или поздно сделают.
Я понял. Скорее всего для кортежей скорее всего можно извратиться. Но костылище будет еще то, не факт что будет иметь смысл такие извращения.
Отдельный метод, принимающий кортеж, у которого обязательства вернуть кортеж строго с такими же типами. Внутри обработчик, принимающий union type, обрабатывающий типы и инкрементящий. И при возврате проверка, что тип кортежа не изменился.
В Ceylon нет многого из того, что есть в Scala. В Kotlin аналогично :).
Вот для такого на самом деле в текущей версии языка придется делать кое что покруче чем скобки:
То есть для z пришлось имитировать итерированием по последовательности из одного элемента. В будущем обещают let разрешить внутри for comprehensions, пока так.
Future по идее можно привести к коллекции из одного элемента. Примерно таким же способом, как я с z извратился.
async await планируют в будущем, но не знаю сколько лет еще ждать. Я пока вместо asinc await просто rxJava использую. Плюс у меня есть библиотечный async метод, который стартует Java поток. Возвращающий Observable. Соответственно внутри потока могу стартовать еще с помощью async другие потоки, и далее у Observable вызываю blockingFirst. Пока не появится async await в языке — живу вот так.
На самом деле Ceylon достаточно неплохо работает с Java коллекциями и в принчипе взаимодействие для программиста незаметное. Правда пока можно нарваться на багу взаимодействия с Java, в результате чего может не скомпилиться и придется искать обходные пути, фича новая и не все крайние условия пойманы. Касается баги в основном преобразования цейлоновских лямбд в Java лямбды — часто это работает, а если не работает приходится по старинке генерировать анонимный класс что громоздко.