Ухудшение технологий программирования

для свого часу і можливостей — чудовий інструмент

Конечно, отличный. Быстро налупашить «формочку» — вот оно, счастье. Только одна проблема — сама среда программирования поощряла нетестируемую и нетестированную код-лапшу, что в соответствии с принципом наименьшего сопротивления породило тонны говнокода и армии людей, не понимающих базовые принципы дизайна ПО.

Ну и что? Большинство из этого работало намного стабильнее и на порядок быстрее, чем сегодняшние пирамиды фреймворков и интерпретаторов.
Изменилась сама модель распространения софта — это дескопный софт и подкосило.

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

У меня другие воспоминания — софт без какого-либо покрытия тестами, в котором «все связано со всем», в результате чего внесение даже простых модификаций было равносильно ходьбе по минному полю. Да, в итоге это работало, но какой ценой?

Ну... в 1995 году пора тестов ещё не пришла. Я много работал с Delphi, и откровенно плохого кода не встречал. Единственное проблемой я бы назвал копипаст — система событий просто мотивировала копировать код из одного обработчика и вставлять его в другой.

Ну... в 1995 году пора тестов ещё не пришла.

Она пришла сильно раньше. Но среди типичных применений Delphi (и большинства аналогичных средств) в те времена в наших краях, да, такое редко применялось.

Поддрежка unit-тестирования в Delphi появилась примерно с выходом книги К. Бека «Экстремальное проргаммирование» (2002), тогда появился пакет DUnit, которые позволял писать unit-тесты и запускать их из среды. Кстати, среда IDE Delphi была расширяемой, вместе с любым компонентом ты мог добавлять код, который выполнялся в design time.

Ну а что было в наших краях на PC в то время? Clipper и FoxPro. Delphi и VB. Разные компиляторы C: Watcom, VC, Borland C++, DJGPP. Плюс некоторая экзотика вроде Turbo Prolog, ... Если кто и хотел использовать тесты — приходилось писать всё самостоятельно ручками.

софт без какого-либо покрытия тестами, в котором «все связано со всем»,

Ну одно с другим особо не связано (покрытие тестами, которое вообще уже для веб-кодинга придумали) и фиговый код, начиная от спагетти и заканчивая бесконечным копи-пастом сущностей.
В целом же поправить и доделать что-то на Дельфи-С-билдере было намного проще, чем в сегодняшних Ангулярах+RoR, например.

новые типа IDE Atom, Visual Studio Code на электроне

це не IDE, це редактори

Кооперативная многозадачность — она такая :)

«Беги, дядь Мить» ©

Как бы не очень.
Функциона́льное программи́рование — раздел дискретной математики и парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).
ru.wikipedia.org/...​ональное_программирование

Тогда чистых функциональных языков раз два и обчёлся, Haskell, ML не знаю что ещё. Которые, однако, не очень популярны. И да, кроме преимуществ есть недостатки.

Недостатки везде есть. И в императивной парадигме, и в ООП. Lisp еще есть. Бабаян по моему даже компьютер делал на основе функциональной парадигмы. Что-то ему с параллельностью понравилось. Не знаю чем закончилось.

Я согласен что как-то сложновато. Но, что-то там есть. Я не могу пока сказать что. Императивную парадигму и логическую объединил. Событийную тоже. С функциональной никак не определюсь. Как-то она у меня слишком сбоку. Мне даже функции пока не понадобились. Хотя вроде магия рекурсии. Лямбды, иногда хорошо. Функции в качестве параметров-круто.. Но, больше никак не нахожу место..

Или Akka cluster. Давайте попробуем нанять 3 вменяемых скалистов или эрлангистов миддлов.

А в чем проблема нанять эрлангистов? Джависта нормального тоже не всегда найдешь, и что?
Я к тому, что у человека может быть подход, который не стыкуется с этой всей фигней.

с какой фигней? с тем, что программист не должен быть девопсом?

это луддизм чистой воды.

эрланг — крайне убогий язык в сравнении с нормальными ФП языками. ничего не мешает использовать акторы в Хаскелле.

огромное кол-во задач, которые решал эрланг уже давно решают кафка плюс кубернетес, причём гораздо более доходчиво для широкой публики решают.

правда в том, что для 99% crud приложений акторная система — гораздо бОльший overkill, чем приложения на Спринге которые контролирует Кубернетес, где де факто поды решают абсолютно те же вопросы, но долее универсально.

Кубернетес можно заменить на что угодно, я абсолютно не фанат этой конкретной имплементации. Можно вообще без контейнеров обойтись, а делать a la Titus — использовать пуллы машинок в тех же целях. Суть от этого не меняется — управление инфраструктурой все больше отделяется от программирования бизнес-логики и я считаю что это замечательно.

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

Дык а сколько оверхеда на дополнительные вычислительные ресурсы сожрёт кафка + кубернетес, в противовес эрлангу? Я раньше работал в компании, где расходы на AWS отъедали половину прибыли.

в еліксір менший поріг входу і більше плюшок

Взоржав...

iex(11)> elem(pref, 1)
"Pre"
iex(12)> elem ( pref, 1 )
** (SyntaxError) iex:12: unexpected parentheses. If you are making a function call, do not insert spaces between the function name and the opening parentheses. Syntax error before: '('

iex(12)> counter = 0
0
iex(13)> counter +1
** (CompileError) iex:13: "counter +1" looks like a function call but there is a variable named "counter", please use explicit parentheses or even spaces
iex(13)> counter + 1
1
iex(14)> counter+1
1

таке синтаксичне лайно ніяк не знижує поріг входу, навпаки.
І якщо ви це називаєте плюшками... у мене для вас погані новини.

Ах да... кращий спосіб знизити поріг входу це назвати байндінги змінними. Типу, знайомий термін для зовсім іншого явища — це найкращий метод завлекти новачків, які, зрозуміло, поламають собі ноги на цьому, але це буде пізніше.

плюшки — метапрограмування

erlang parse_transform був роки тому до elixir.
Єдине що — викликати його треба було окремими правилами.
Можливість на ходу скомпілювати код і виконати його — теж.
А от те, що скомпільовані функції залежать від версії похідного модуля, може бути критичне, а тут воно ніяк не показується.

Я так розумію, один частковий випадок?

Ах да... кращий спосіб знизити поріг входу це назвати байндінги змінними. Типу, знайомий термін для зовсім іншого явища — це найкращий метод завлекти новачків

Эликсир идет чуть дальше, чем просто переименовать в документации что-то. В эликсире, в отличие от, можно counter = counter + 1 (хотя под капотом же все равно эрланг, так что никакого «ребайнда» в реале не происходит — насклько я помню просто создается новый байндинг а компилер трекает «алиасы», скрывая от кодерка кишки). Очень спорный дизайн местами, имхо...

Хм, прикольно. Такая себе самодельная переработка в SSA поверх движка с неизменными значениями. Но осмысленность уровня троллейбуса из буханки.

Ну так написані нормальні помилки, в чому проблеми то? В тому, що є примус до форматування коду?

В дурості конкретних вимог самого примусу. Приклад с +1 це показує.
Варіант, коли пробіл ставити треба завжди, логічний по-своєму. Маємо синтаксис стилю LISP, Forth...
Варіант, коли пробіл не має ролі, теж логічний. Це традиційний синтаксис як у мейнстрімі (від Паскаля і C до Ерланга і Go...)
А те, що бачимо у Elixir, не має ніякої логіки крім одного — засобами типу PEG встановили приорітет розбору, наплювавши на однозначність.

То-то как только испекли ребар, 90% (если не 99%) эрлангистов перебежали на него, наплевав с высочайшей колокольни на возможность выполнить relup и прочие тонкие задумки Армстронга.

Если чтото может упасть, оно падает.
Как бы транзакции не от хорошей жизни придумали.
У меня и на питоне let-it-fail на не-реалтаймовых поточных сервисах. В некоторых случаях так проще, чем потратить х5 времени на учет всех проблем.

Если чтото может упасть, оно падает.

А это независимый вопрос. Что упало — перезапустят. Но если падает 1% от всей функциональности, а остальное работает, то зачем перезапускать всё, если можно ему дать продолжить работать?

У меня и на питоне let-it-fail на не-реалтаймовых поточных сервисах.

Я б рассказал, как на поточных сервисах я почти каждый день перезапускал считалки и делал магические пассы, чтобы они работали, но не хочу слишком пугать народ :)
В пять раз — это аргумент. Но только там, где таки во много раз (эх, Ра).

Перезапускал ручками? ну тогда да,вам надо кучу всего чтоб поправить карму
скрипты которые падают чаще раза в МЕСЯЦ запускаются с резирвированием х2 с помощью safe_xxx.sh и в них ставятся таймауты. Отработал ХХХХ запросов — вышел, перезапустился.
Упал? Положил в лог сообщение о падении, перезапустился.
Так еще с времен до-апача-1.0 сделано везде.

ну тогда да,вам надо кучу всего чтоб поправить карму

Я и поправил — ушёл оттуда :)

golang, язык, в котором ничего нет

если есть мозг

А с этим собственно и проблема. Поэтому появилась Java, эти ваши питоны и Go. По последнему это даже не скрывалось — щас не найду цитату, но смысл был в том, что в Google устраиваются выпускники универов, которых учили чему-нибудь и как-нибудь, всяким Java, C++, и всё это не то и не работает. Поэтому вот вам язык, на котором типа невозможно писать неправильно. Даже go fmt есть.
Если бы был мозг, то не нужно было бы вообще ничего кроме С.

Если бы был мозг, то не нужно было бы вообще ничего кроме С.

Ну, если бы кто-нибудь тут не сказал настолько радикальную и феерическую глупость, это был бы не dou.

І правда — нашо той С, коли є asm?

Табличку SARCASM було б варто вже давно мати на ДОУ :(

Grapefruit shutdown... fastfood shutdown...

Shitfood shutdown еще.

JVM? — тормозит, потому что Java тормозит!

Она не то, чтобы тормозит на фоне современных интрепретаторов, но память жрет как свинья и выдает не менее свинские логи с эксепшнами, для парсинга которых нужна еще одна машина с еще одной явой (привет ELK!) и так по рекурсии.

память жрет как свинья

В абсолютных величинах — давно ограничивается. В темпе роста — с современными GC это в основном решено. Я удивлялся, почему не сделают ближе к стилю Lua (грубо говоря, следующая сборка запускается по достижении K раз от результата предыдущей), но то, что начинается где-то с 8ки, меня устраивает почти всегда.

выдает не менее свинские логи с эксепшнами, для парсинга которых нужна еще одна машина с еще одной явой (привет ELK!) и так по рекурсии.

Красивое утрирование, и в качестве хохмы пойдёт, но на практике — нет. ELK не обязателен (а лучше сказать — не нужен чуть менее, чем всегда), для логов вылета кода под VM достаточно grep+less. Конечно, если стоит задача хипстерски обосновать выделение ещё 100 VMок, то надо решать наоборот :)

В абсолютных величинах — давно ограничивается.

Оно в любом случае ограничивается объемом памяти инстанса или хардлимитом контейнера. Поинт не в этом, а в том чтобы стандартный тул на яве с машиной меньше 2 гиг озу лучше не подходить, а лучше с 4мя сразу. А это деньги в современных облаках и клиенты жутко не любят их туда сливать.

Я удивлялся, почему не сделают ближе к стилю Lua (грубо говоря, следующая сборка запускается по достижении K раз от результата предыдущей)

Долго стартует.

для логов вылета кода под VM достаточно grep+less

Успехов в вылове ошибки на сервисе с нагрузкой хотя бы в 1000cpm, произошедшей 8-12 часов назад (но точно неизвестно когда). А еще лучше — навесом извне алерта с ее полным описанием.

Поинт не в этом, а в том чтобы стандартный тул на яве с машиной меньше 2 гиг озу лучше не подходить, а лучше с 4мя сразу.

Что-то я такого не наблюдаю. Сколько сервису реально нужно, столько и отдавать надо, только выбрать разумный коэффициент для облегчения GC (типа, 2 раза от суммы всех объектов — где-то минимум нормы, 3 раза — ему чуть полегче, и всё такое). А абсолютные цифры могут быть совершенно разные — где-то 200M хватает, а где-то и 30GB выжирало.

Долго стартует.

Чивооо? При чём тут скорость старта к этому методу?

Успехов в вылове ошибки на сервисе с нагрузкой хотя бы в 1000cpm, произошедшей 8-12 часов назад (но точно неизвестно когда). А еще лучше — навесом извне алерта с ее полным описанием.

Вы контекст-то на ходу не меняйте. Именно лог вылета по исключению — ищется и читается банально. Вот если не стоит задача «есть неизвестное исключение => дорабатываем, ставим явную защиту и т.п.», а надо понять картину в сумме — то да, может быть, и ELK надо вкручивать (хммм), но это уже другое.

А что это у вас за ошибка «неизвестно когда» — это вообще что-то совсем странное. Если вы знаете про ошибку, то как вы не знаете, когда она произошла? Нет, я могу себе представить, как до такого довели, но зачем доводить?

Что-то я такого не наблюдаю.

К-мон, давай любую известную утилиту или софтину на яве. Попробуем ее вместе запихнуть в 512 метров (порядка 300 за вычетом операционки) и дать нагрузку.
Я не говорю, что нельзя написать и посчитать хорошо, я о том что этого никто никогда почему-то не делает все сводится у «если оно падает на -Xmx512, поменяйте на -Xmx1024 или 2048».

то как вы не знаете, когда она произошла?

Может, потому что о ней сообщил клиент? Который, скажем, в Чикаго? Или вспомнил на следующий день (а то и в понедельник)?

К-мон, давай любую известную утилиту или софтину на яве. Попробуем ее вместе запихнуть в 512 метров (порядка 300 за вычетом операционки) и дать нагрузку.

Cassandra. Как раз под нагрузкой — поток асинхронных insert’ов около 5K/sec, ключи в основном разные. RSS прыгает 470-490M. VSZ 2.2GB, но не показателен, там уже libc’шный malloc способен отъесть гиг на таком старте. Подскажите, как получить данные именно про java heap size, я с ходу не нашёл.

Может, потому что о ней сообщил клиент? Который, скажем, в Чикаго? Или вспомнил на следующий день (а то и в понедельник)?

Так логи-то есть или нет? Если есть, в них ошибка не видна и надо её вычислять? Тогда это не stacktrace.

Cassandra.

Хмм...
«...a minimal production server requires at least 2 cores, and at least 8GB of RAM. Typical production servers have 8 or more cores and at least 32GB of RAM.»
Но это не очень хороший пример, т.к. Cassandra все-таки достаточно уникальный продукт и альтернативы особенно и нет.

Так логи-то есть или нет? Если есть, в них ошибка не видна и надо её вычислять?

Логи есть, разумеется. Иначе вычислять нечего. Но вот эксепшнов в них может быть сколько угодно за это время, а найти нужно именно какой-то уникальный. Причем заранее неизвестно — какой именно.
Поэтому все это барахло и нужно собирать обратно в одну запись, укладывать в колоночник, там фильтровать мусор, убирать в сторону разное секюрити и статистику и оставлять только нежданчики, на которые уже вешаться нотификэйшнами.

OK, пусть так. Всё равно утверждение про рекурсивность кажется перебором. Если Elasticsearch будет глючить, есть множество других способов вести логи и находить в них нужные записи. Хотя я бы вообще тогда подумал избавиться от E :)

А указанные пожелания для Cassandra — удивляют — у нас таки на 1/5-1/10 от указанных работает беспроблемно. Хотя если требовать с неё миллионы операций в секунду — может, и нужны такие цифры :)

Cassandra все-таки достаточно уникальный продукт и альтернативы особенно и нет.

Scylla. Теоретически, дроп-ин замена кассандры (и чуть ли «тот же код, переписанный на плюсах» — что бы это не значило).

О, спасибо. Посмотрю на досуге.

Совсем недавно ещё очень жестоко глючила, в продакшен нельзя было пускать.

Вообще же насчёт уникальности — если по фичам, то есть ещё как минимум Riak, CockroachDB...
я-то понял уникальность как в плане дизайна.

Уникальность была заявлена в поддержке ACID, но что-то пошел вчера по ссылкам на текущее состояние обеих софтин и загрустил...

требование делать микросервисы идёт от бизнеса, мне они не нужны в данном случае

меня никто ничему не учил, все собственный опыт. я не доверяю ни одному решению, пока оно не покажет себя в моем же проекте достаточно устойчиво и просто.

простые IO веб сервисы на сях — ололо. почему не на ассемблере?

а какой еще может быть ответ, если есть монолит 7+ лет на php, в который уже давно не невозможно впилить ни одну фичу без боли?

хорошо, что бизнес хочет выйти из подобной ситуации.

Ня: habr.com/ru/post/188114

Ты уверен что все те 10 микросервисов нельзя заменить одним компактным монолитом на сях и выбросить весь этот список доп технологий в мусорник

... А через пять лет в этих помоях копаются уже десять несчастных команд, плача каждый раз когда эту каракатицу надо завести на локалке 😅

да где угодно ее завести будет больно.

вы видели legacy на c++ хотя бы раз в жизни? причём на плюсах почти весь код — сразу легаси, если кодерок аутсорсный миддл

Я тащемта о монолите и говорил... Легаси на плюсах видеть увы довелось

почти весь код — сразу легаси

А в чем, вообще, проблема с легаси? Чем оно мешает?

Я видел много примеров, когда монолит разрезали на микросервисы и проект или умирал или улетал в невероятные эстимейты

«Много» — это сколько? Олсо, то, что у кого-то что-то не получается, не значит, что это что-то неприменимо. Это значит лишь то, что у того, кто попытался применить, не получилось.

ниразу не видел обратной ситуации, когда проект загибался только потому что он монолит, а не микросервисы.

Проекты не загибаются потому что они монолит или не монолит. Они загибаются, потому что финансирование заканчивается или потребность в проекте отпадает, или потому что какой-нибудь вася не написал хороший юнит тест и 200 человек упали на землю вместе с самолётом, например, и теперь компании, выпускающей проект, никто больше не поверит. Мой поинт в том, что техническая сторона проекта даже на 50% не кореллирует с его внешним жизненным циклом.

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

Это слишком абстрактно. Ваш вывод, что «монолит разрезали на микросервисы и проект или умирал или улетал в невероятные эстимейты» очень контекстный — какой проект, какой монолит, какая сложность, и миллион других условий от менеджмента до уровня девелоперов и архитекторов — всё это влияет на стоимость и эффорт. Может получиться так, что проект на микросервисах в конечном итоге будет гораздо легче сопровождать, чем продолжать жрать монолитный кактус.

Айти менеджеры продают решение бизнессу, что все надо переписать по-взрослому, по микросервисному

Ни разу такого не видел. Я бы хотел посмотреть на бизнеса, который купит именно идею «переписать всё на микросервисы» (именно в такой формулировке). Обычно это подаётся как часть эволюционного процесса зашедшего в тупик сложности монолитного проекта. В этому случае продолжать развивать монолит зачастую кажется более дорогой задачей, чем начать мигрировать на микросервисную архитектуру в эволюционном порядке.

Есть и писимистичный сценарий, когда проект с самого начала начинают пилить «по-взрослому»,

Это не пессимистичный, а какой-то эльфийский сценарий. Я думаю, что он конечно возможен, но только в том случае, если архитект — вчерашний школотон с адским микросервисным запалом в заднице. Пилить проект сразу как микросервисы — это как минимум неразумно и никто так не делает, потому что практически никогда невозможно точно спрогнозировать, где будут лежать границы конкретных доменов, на основе которых и рекомендуется нарезать микросервисы.

Текущий мой проект. Три команды делало, на 500rps загибалося(по словам клиента).
Я переписал с использованием очередей и параллельных микросервисов — все работает, уже 10к rps и все ок.
когда как.

на такому ж обладнанні?

Почти. Второй SSD только добавлен, чтоб хранить результаты( 50GB в день генерит).
Справедливости ради, изначально там оборудование вида E5-2690 v4 dual(54 ядра по 2.6), 128Gb ram, SSD.

Текущий мой проект. Три команды делало, на 500rps загибалося

на чем делало? может руки кривые у папереников просто?

А фиг его знает. Мне не показывали результат.
Может и кривые, а что это меняет в принципе?

Это субъктивная оценка. С чьей-то точки зрения проект загнулся на этапе монолитной системы, и использование микросервисов были реанимационными дествиями, которые не принесли успеха. Всё-таки переделки такого масштаба это показатель неудовлетворительности работы. А для кого-то виноваты микросервисы.

Ну а спору монолит или микроядро много лет. В монолите есть проблема, что какой-то логгер может закрашить всю систему. Не говоря о том, что монолитный код часто со временм превращается в монолитную систему, в которой нет логического разделения на сервисы, и перевести его на микросервисы задача не из лёгких. Плюс все сопутствующие пробелмы. Ну и в C++ мало готовых асинхронных решений, всё-таки путь C++ это многопоточность. А это может быть полезно и упростить жизнь.

В случае потоком ты атомиками и алгоритмами без блокировок и барьеров можешь обойтись, с процессами так не покатит

Хто заважає процесам так спілкуватись через шарену пам’ять?

Так тими ж атоміками й синхронизуватись можна.

Никто не мешает тебе использовать многопроцессность

Я хочу использовать асинхронность, а не многопроцессность/многопоточность. С точки зрения того же Linux разница между процессом и потоком только во флагах, которые передаются в метод clone, так что это во многом синонимы.

Ну а если потоки/процессы работают с одной памятью, то атомики и отсутствие блокировок могут никак не помочь. Из недавнего опыта два потока — в полтора раза медленнее, восемь потоков — в четыре раза медленнее даже с отключённой синхронизацией. Всё съедает обновление кэшей на ядрах, MESI/MOESI, ...

Позвольте, но это же будет не прикольно! ;)

Есть, но они очень не массового выпуска.

Ну, вот, например, чем не вариант: budnitzbicycles.com/technology (тут даже рубашки, походу, вечные).

Они устойчивы

Нiт, так же как и карданная передача. Сочленение шестерня-шестерня плохо реагирует на регулярные удары, неизбежные при прыжках на mtb. Перекидки же, напротив, крайне гибки, и эволюционируют, чтобы трястись и выпирать меньше (shadow, а потом и shadow+ в shimano, и аналогичные им в sram, которые уже перекочевали из топовых линеек в рабоче-крестьянский deore).

Вообще насыпные подшипники используют только в велосипедах. Нигде на производстве, на станках, в моторах

Вы таки видите профит от облегчения станка? А вот −100грамм неподрессоренной массы это как гантели с ног снять.

ценят старые простые и надежные велы

Если не на трейлах и трассах/треках (где можно и over $10K запросто увидеть), то я почему-то в Берлине и Вене наблюдал в 90% случаев рассыпающиеся от ржавчины китай-велы на восьмерящих ободах. Не совсем ашан, может, но близко. Что-то худо-бедно уровня бюджетного cube видел всего пару раз.

100 грамм для колеса это вообще ниочем

Це взагалі то дофіга. Я завжди виберу −100 г з колеса ніж −500 г з рами.

+100грам для туристического(идущего ровно по дороге) сильно предпочтительнее прокола.
У меня есть и тяжелые и легкие покрышки(вел легкий), обычно езжу на тяжелых marathon supreme 29(0.7 только покрышки), ибо нет времени на перебортовки колес. а герметик — те же яйца в профиль(вес).

если не забыл взять ремкомплект, и блин эти современные насосы. Вот чего нельзя хоть манюсенький но ШЛАНГ

Угу. Только нужен хотя бы карман или сумка, чтоб его возить. Нафиг нужно.
Еще раз, при неагресивном крос-кантри или в городе проще взять покрышки с защитой или кевларовую ленту.
У меня последний пробой на этих покрышках был в 2010м году. Гвоздем с круглой шляпкой, обивочным.

хорошо хоть не на порнхаб послал. Все таки влияет С++ на тестостерон

точно, благодаря Java и физо

Из компактных Fabric Nano: шланг достаточный, чтобы не насиловать нипеля, и скрывается в сложенном состоянии.

img0.reactor.cc/...​ница-фэндомы-3098988.jpeg

Ага,ага. А если мороз? А если дождь? А если вся поездка 30 минут
Вобщем если не горы, то стоят тяжелые Supreme, насос можно не возить(ну кроме Одессы осенью, колючки пробивают все).

А если мороз

Минус гидравлика: тормоза, вилка, а если много снега — то еще и минус передние (как минимум) передачи, и фетбайк. А если еще и гололед — то еще плюс шипованная резина.

А если дождь

Без особых проблем, разве что лучше смазку на цепь для влажной погоды.

Что касается бескамерки, как-то проколов в разы меньше, чем даже с дубовой резиной, плюс заментно легче, и сцепление лучше, а почти все проколы затягиваются геметиком сами сразу, иногда только слегка подкачать надо. Но с наличием насоса с капсуалами CO2 под давлением — и это не больше 3х секунд занимает. А вы говорите — прогресса нет.

Это комент был про перебортовать.
А так то в мороз у меня чегото гидравлика работает.
В разы меньше ... НУЛЯ? не, ну если так, то супер. Только я пробывал как бы.

В разы меньше моего опыта на камерах, в т.ч. с антипрокольными покрышками.
Гидравлика до −15 где-то работает более-мение, да и то зависит, масло или дот. Хотя по морозу антипрокольная жидкость — тоже плохая идея.

Не завжди є можливість мати додаткові колеса (бо це іноді $$1000-2000 додаткових грошей) і така розкіш як машина підтримки любителям не доступна. А на тріатлонах так взагалі заборонена.

Я з собою просто маю додаткову трубку в сумочці під сідлом і пару CO2 картриджів для швидкої зарядки. В залежності від того наскільки захекався поміняти трубку займе від 3 до 5 хвилин. Це багато, але серед аматорів, та ще і на довгих дистанціях має сенс продовжувати гонку.

Возити з собою насос та набір для заклеювання? Можна, але у вело-подорожах, а не на тренуваннях та змаганнях.

Це коли ти профі і заробляєш цим на життя. За мною, на жаль, машина з механіком і запасними колесами не їздить.

В шимано почти везде во втулках — насыпные. И честно говоря, проблем с ними нет даже у меня(вес 120 и прыжки).

Та можна, у мене на роботу в одну сторону 25-30 км виходить. Єдине що кошик для бутилька молока нема куди прикрутити.

Ось буквально сьогодні з ранку — www.strava.com/activities/2441780117. З роботи той самий маршрут мабуть. А коли працюю в офісі в Сіетлі то 34 км виходить в одну сторону.

Це теж, але коли пересідаєш на новий байк то різницю все одно чути. Навіть різний за складом карбон рами помітно відрізняється на дорозі (підйоми, спуски, прискорення), компоненти, колеса — все це впливає.

с центральным двигателем цепь со звездами как раз изнашиваются будь-здоров

купить вещь которая прослужит мне тихо и мирно нескольк лет

Для деяких речей — так. Для інших (як компоненти вела) особисто я хочу щоб постійно щось було новіше і можливо навіть краще, щоб я міг апгрейдити свій вел і отримувати свою порцію щастя. А комусь телефони з новими фішками ледь не щороку давай, комусь ще — машини, і так далі.

Згоден. Я про те саме і кажу — в більшості випадків для абсолютної більшості товарів люди хочуть щоб надійно, зручно і на довго. Але все одно у кожного щось таке знайдеться що хотілося б оновлювати постійно. І серед велосипедистів таких достатньо щоб час від часу з’являлися покращення на ринку.

Я не фанат Apple, но вот живой контрпример: iPhone 6s. Пережил обновления iOS с 9 по 12ю, кучу обновлений софта, и до сих пор (тьфу-тьфу) не окирпичился, не тормозит и не глючит.

Разве что, аккумулятор поменял в нём, но тут ничего не поделаешь — физический износ.

в 1900м году придумали трактор который проработал без особого ремонта 50 лет.

Дивно, чому ж тоді зараз ніхто не хоче на такому чудовому тракторі працювати? Може справа в тому що наступне вдосконалення в тракторобудуванні якраз і сталося лише через 50 років, а зараз такі трапляються по кілька разів на рік?

уже проходили www.oreilly.com/...​pensources/book/appa.html

И стоить в 2 раза дороже.
И покупать новую железку при обновлении ОС.

Ну в S/360...z/Series с её канальной подсистемой где-то так и получается: даём команду «читать» и пусть оно само по себе отрабатывает остальное.

Но всё равно остаются особенности, которые не уложить в эту схему.

У него вроде была идея что сам девайс должен внутри содержать эти дрова.

Хорошая идея. И я ее реализовал.

Когда-то с ООП у него получилось

А получилось ли?
...I’m sorry that I long ago coined the term «objects» for this topic because it gets many people to focus on the lesser idea. The big idea is «messaging»...

Эта идея реализуется через Actors

А что сложного простенькую ось с микроядром написать как дипломную? В качестве загрузчика можно на асме быстренько набросать и даже GRUB не использовать, потом менеджер памяти и обработчик прерываний пишешь. Уже почти ОС, осталось добавить простой шелл и файловую систему. Вуаля. Самое сложное это файловая система и управление памятью, но опять же в том же Танненбауме это хорошо описано. Времени это займёт где-то часов до 80.

С учётом библиотек, я думаю, что 80% кода (не удивлюсть и цифре 95% в отдельнх случаях) никогда не будет вызвано вообще (мёртвые ветки if, переопределённые виртуальные функции, ... Из оставшихся 20% да, 4% делают основную работу, 16% для всего остального.

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

Здесь тоже ничего нового.

Будут продолжать автоматизировать все что автоматизируется за реалистичное количество ресурсов.

А вот тут есть как раз проблема о которой я и говорю.

Дальше только ждать скачка в мощностях..типа всяких вычислений на квантовых компьютерах, а так только банальное ковыряние из пустого в порожнее.

Квантовые вычисления это вообще другая тема.

Хтозна: швидше за все до 2038 року 64 біта буде вже всюди

так то оно так, но лично мне трудно уживаться с людьми, а тем более думать что мы конкуренты в какой то мере, которые на ссылку на документацию по проекту тебе говорят «я фронтенд, я не обязан разбираться как базу из дампа залить и настроить окружение локально» и бежит жаловаться пму что ему ничего не помогают сделать или за него не сделали... ПОживем увидим, здается мне сейчас что то подобие пика наплыва, который какое то время еще подержится и возможно пойдет на спад, а это еще может лет 10 уживаться и подстариваться под всякие новомодные бредни...

Я сильно підозрюю, що ми спостерігаємо несвідомий пошук людством якоїсь навіть не ефективної, а хоча б життєздатної парадигми системобудування, як процесу. Системобудування в загальному смислі. Цей пошук йде у добре знайомий нам з біологічної еволюції спосіб рандомних спроб та помилок. Тулзи/фреймворки виникають, мутують, форкаються, конкурують та виздихують пачками. Окремі вдалі концепції виживають та масово нерестяться, породжуючи кодли нащадків, жахливих, як формально, так і в імплементації, після чого цикл повторюється. Деякі базові рішення виявляються напрочуд життєздатними, як таргани чи нікси, або тцпіп, або 3-тієр, або рсубд чи CLI. Інші або здихають у корчах миттєво, або вкорінюються в вузькоспеціалізованих еконішах, або провалюються у потенційні ями, з яких вже нема жодного перспективного напрямку розвитку.

Всі ці фреймворки, мови, парадигми, концепції, що плодяться без ліку, мають на меті не загальне щастя чи розумне-добре-вічне, а виключно перемогу над конкурентами у доступі до ресурсів у вигляді CFO/CTO. Як вірусам байдуже, що буде з організмом, що вчасно не знищив збудників хайпу, так і трендовим технологіям байдуже, чи виживе ентерпрайз, який вони інфікують. Їхня задача — урвать свій шматок ресурсів у безжалісній війні між- та внутривидової конкуренції. Це метаеволюція, рушієм якої є зовсім не комфорт девелоперів, не КРІ і не SLA, не котування шерів. Технології живуть власним життям, строго за Докінзом, а ІТ та ітшники — це субстрат, в якому вони живуть.

То й що? Це нічого не міняє.

Власне, нам байдуже, чи еволюція у ретроспективі була наслідком початкового розумного дизайну, панспермічної інвазії, а чи зовсім локального статвибрику. Нас цікавить лише подальший розвиток еволюції, а в усіх випадках він строго тотожній. В гуманітарному смислі питання «як все почалося?» має певний сенс і певний інтерес, але у чисто прагматичному ключі нас має цікавити лише одне: якого розміру клізми потребує поцієнт.

а які вони тоді були ?

:) обожаю такие коммены. Обидно за девопс или сре ?

Ну как разобраться...
Сейчас кмк и саппорт по принципу скрама выходит — за неделю не упало, и ок.
Упало и не поднимается — нанимайте новую команду разрабов и пилите новую версию (старых уже хрен найдешь, а девопс-админ не бог и этот набор костылей на костылях обратно собрать может разве что случайно).

Ті хто робили софт під різні платформи все ж таки мали сподівання що Write once, run anywhere буде правдою. Але через кілька років стало зрозуміло «вам так не буде».

Нефига. Берешь какойто старый код, вот к примеру vtiger connector for asterisk. Пытаешься его запустить — а нет, не работает он в текущей джаве. ВООБЩЕ. А исходники походу потеряли ;) Так тоже бывает.

jar конечно. Код потеряли. Случайно ;)
А под виндой оно, кстати, вообще никогда не работало.

Ну... сейчас всё к этому приблизилось. Ну в случае нативного кода надо будет перекомпилировать.

Не говоря о том, что мне трудно особзнать необходимость кроссплатформенности на бэкэнде. Я могу понять, что существуют сотни различных отличающихся по железу мобильных телефонов, и хотелось бы писать код один раз. Но бэкэенд очень часто принадлежит одному владельцу, поэтому почему бы не использовать все преимущества одной платформы?

Ага, у одного MS SQL, у другого Oracle... И в результате получается продукт, который не может использовать преимущества платформ (потому что раз это преимущество, значит оно где-то да отсутствует), и не может перейти линию самого худшего всех платформ.

А что это не так? Write once, run everywhere — булшит. С выходом 9-й джавы с совместимостью кранты и дальше все хуже. Вчера скачал Бамбу, установил, а он не работает под JDK 11. Пришлось ставить 8-ю Джаву

Та там і без дев’ятої... Як плюсовик, я з нею стикався перш за все через JNI на Android — і там це тупо окремий світ. На десктопі з іншого боку я з нею стикався як юзер. Я хз як там воно влаштоване в середині, але що Eclipse глюкає на OpenJDK й більш менш працює на колишній санівській яві — факт.

А зачем один стандарт? Мне нравится Ember.js, тем что много есть из коробки и задает некоторую структуру проекта. Другим нравится vue/react, за противоположные качества. Есть ещё требования к проекту и какой-то проще будет делать на определенном фреймворке.

А жквери вообще не фреймворк, это библиотека для работы с DOM и ajax. Как раз в Ember.js он доступен из коробки по умолчанию (хотя вроде бы можно вырезать при желании) и вполне успешно можно использовать в отдельных компонентах.

ну это как раз пример моднячих а не разумных решений. Люди постоянно ищут какую то серебряную пулю которая решит все их проблемы но в большинстве случаев пули оказывабтся из говна

А что не так с микросервисами?

Да и про докер спорно.
Это разве что с точки зрения кодера, когда горизонт видимости ограничен коммитом в гит, а что там дальше — «черная магия».

преимущества контейнеров на стадии разработки и тестирования очевидны как замена виртуалок. Но не вижу преимуществ на продакшене где это толко лишняя прослойка.
В каких нибудь SAAS сервисах или порталах типа яндекса может быть и оправдано но большинство веб приложений это просто сайты и не коробочные решения а сделаные под конкретную задачу и на конкретном стеке для которого приложение оттестировано — и что тут дает применение контейнеров?

...серебрянная пуля на данный момент для большинства веб/мобайл/ML приложений...

...большинство стартапов умирают в первый год существования...

Совпадение? Не думаю!

«Если автоматизировать бардак, то получится автоматизированный бардак» © Как меня учили в 90-х годах.

И тут проблема не в инструментах, а в человеческой вере в то, что есть системы автоматического разруливания бардака.

у крупных компаний до фига денег они могут с легкостьбю нанять пять програмистов на яваскрипте там где справится один на PHP
Хотя часто сложные решения оправданы — понятно что сервисы гугла такие как гуглдокс или сервисы фейсбука требуют сложных решений и фреймворков. Но потом эти реакты ангуляры и ноды пиарятся ими и начинают юзатся обычными компаниями в проектаз где даже близко подобная сложность не оправдана.

пять програмистов на яваскрипте там где справится один на PHP

Там где справится один на пхп, справится один на жс.

ноды пиарятся ими и начинают юзатся обычными компаниями в проектаз где даже близко подобная сложность не оправдана

В ноде нет никакой сложности в наше время, кроме понимания асинхронности и возможно замыканий. Во всем остальном все равно на чем писать АПИ — на пхп или на жс.

Там где справится один на пхп, справится один на жс.

не справится потому что php намного проще и эфективнее он изначально создан для веба в отличие от других языков Потому он и такой живучий

Во всем остальном все равно на чем писать .АПИ — на пхп или на ж

суть в том что на сайтах на PHP не нужно никакого API оно
нужно именно для фронтеэд фреймворков .
я уже не говорю что пых идет на любом шаред хостинге что значительно дешевле и не требует администрирования для большинства владельцев сайтов это важно- они заняты своим бизнесом и лишний гемор и затраты на администрирование на ровном месте им ни к чему а на чем оно там написано тем более не интересно

я уже не говорю что пых идет на любом шаред хостинге что значительно дешевле и не требует администрирования для большинства владельцев сайтов

Любому более-менее серьёзному приложению необходима тонкая настройка сервера, а не шаред-хостинг.

они заняты своим бизнесом

Каким например? Очень интересно, какой бизнес такой в айти не требует вложений в разработку собственно софта

Кому-то и сайт-визитка «проект»

ну уж точно не носятся с этим монгодиби и иже с ними как несколько лет назад когда считали что реляционные решения уже в прошлом и на полном серьезе дискутировали что лучше..
nosql решения хорошо справляются в своей нише где им и место
Недавно кстати разработчик ноды покинул проект заявивши что нода хреново подходит для серверных решений — ее ведь разработали для ситуаций когда надо быстро обработать много мелких запросов (типа коментов в фейсбуке) не создавая отдельнй поток для каждого, а не писать целые веб порталы .
Но как раз те кто не хочеть ничего учить решили что они могут выучить один яваскрипт и писать полный стек от сервера до клиента.
каждое решение должно быть в своей нише — именно поэтому старый добрый PHP неубиваем

Недавно кстати разработчик ноды покинул проект заявивши что нода хреново подходит для серверных решений

Давайте-ка ссылочку на цитатку.
Вы переврали его слова.

Гонзо-програмування — наше все!

В случае с Grunt-Gulp-Webpack это не мода, а просто выход лучших инструментов, которые вытеснили старые. Для большинства задач их знать нужно на уровне «знаю, что оно делает, могу добавить лоадер, найдя решение на StackOverflow». Так что, если человек не способен в таком разобраться, он или даже не пробует это делать, или дебил.

По поводу «яваскриптового безумия захлеснувшего веб разработку»... ну я такое слышу в основном от людей, далёких от фронтенда, как Россия от адекватности. Так что даже спорить бессмысленно. В любом языке есть по несколько фреймворков и тулзовин для одних и тех же задач (опуская само наличие кучи языков, на которых можно писать бэк, в отличие от одно JS на фронте). В этом нет ничего страшного.

Сидеть на жопе ровно и хвататься за условный jQuery 14 лет — идиотизм, как и бросаться учить всё подряд. Я вам открою секрет — не обязательно прям всё-всё знать, чтобы работать в современном мире разработки на хорошем уровне.

В любом языке есть по несколько фреймворков и тулзовин для одних и тех же задач

Отличие в том что фронтенд фреймворки не решают никаких задач.
Большинство приложений (кроме каких нибудь браузерных игр) сводятся к тому чтобы взять у пользака данные положить их в БД а затем по запросу выдать в отфильтрованнгм и форматированом виже. С этим вполне справляется бекенд.
Перенос логики и рендеринга на фронтенд только лишняя работа поскольку бекенд все равно приходится писать.
С точки зрения пользователя тоже никаких преимуществ. В начале нулевых помню была мода на всякие флешовые заставки и прочее но ща интернет прост рабочий инструмент и прыгающая и дергающаяся за каждым движением мыши страница только раздражает не говоря уже о тормозах браузеров пытающихся перелопатить мегабайты скрипта в отличие от бекенда который рендерит на быстрых и дешевых серверных решениях
Я как то пытался разобратся в яваскриптовых фреймворках с точки зрения того какие преимущества это даст в моих проектах мне как разрабу и пользователям сайтов и так и не нашел где мне это прикрутить с пользой — jquery и bootstrap закрывают все вопросы с головой. Конечно нужен верстальщик и дизайнер но это и так нужно по любому.
Понятно что для вас это работа и зарплата но я подхожу к вопросу как технарь с многолетним опытом программирования и практический складом ума.
Недавно мой заказчик начитавшись инета решил блеснуть умом и сказал заменить таблицы на сайте на Datatable мол там же уже есть и пагинация и сортировка и экспорт ничего не надо програмировать. В результате страница загружалась 4 минуты пока яваскрипт перелопачивал тысячи строк данных. А на мобиле даже комбики с select2 тупят

Отличие в том что фронтенд фреймворки не решают никаких задач.

Я как то пытался разобратся в яваскриптовых фреймворках с точки зрения того какие преимущества это даст в моих проектах мне как разрабу и пользователям сайтов и так и не нашел где мне это прикрутить с пользой

Это означает лишь, что или вы так и не поняли их преимуществ, или у вас такие проекты, что они действительно излишни. Так что не стоит экстраполировать своё мнение на всё разнообразие задач и вызовов современных приложений.

собирающихся через раз из-за очередных апдейтов можете

таких примеров привести не могу. всё нормально собирается

Лично я использую Vue и у меня таких проблем за 2.5 года работы с ним не возникало.

Очень сомневаюсь, что при апдейте патчевой версии ангуляра что-то поломается, что нельзя починить строчкой-двумя кода (если вообще поломается)

Очень сомневаюсь, что при апдейте патчевой версии ангуляра что-то поломается, что нельзя починить строчкой-двумя кода (если вообще поломается)

Ну, ситуации когда убрали старые баги и добавили новых возможны, но случается такое не каждый день конечно

у вас проект на ангуляре 4.1.2.1, а потом вы его проапдейтили на ангуляр 4.1.2.2

Внезапно обновили? Нравится стрелять себе в ногу?

Апдейт должен проводиться планово, на это нужно выделять время, и это должно идти отдельной таской (кроме случаев когда апдейт необходим для выполнения текущей). После апдейта вы запускаете тесты (если они есть) и руками тестирует основные фичи. И потом, после устранения всех «посыпалось», обновленный package.json и package-lock.json коммитятся в гит.

Если у вас кто-то просто так что-то обновляет, у вас нет процессов. Если у вас в package.json не зафиксированы версии зависимостей (присутствуют ^ и ~), значит вы сами себе виноваты.

Вот! В этом-то и вся писечка. Апдейт не должен все ломать.

Да ну, правда что ли?

Даже в .NET-e перевод проекта с версии 3.5 на версию 4.5 нихрена не ломает и проект билдится с первого раза

Значит фреймворк или не развивается, или тянет за собой легаси по 10 лет. В фронтенд-разработке так не принято и для обновлений мажорных версий нужно читать что изменилось и приводить код к нужному виду. Для минорных и патчевых обычно нет, но всегда могут встретиться баги, которых в предыдущем патче не было. Кроме того, фреймворк никогда не бывает один. Есть ещё сторонние плагины к фреймворку, которые могут стать несовместимы с новой версией, хаки в своем коде, опирающиеся на приватные АПИ.

Нет, это значит, что фреймворк умеет в обратную совместимость.

ну и сколько клиентам на дорогом мобильном интернете будет стоить эта обратная совместимость? Ну и зачем оно тогда надо? Не путайте бэкендовый дотнет с фронтом.
Такое можно будет заявлять когда то же самое получит широкое распространение в WebAssembly и когда от .Net фронт-приложений (Blazor) на этой платформе не откажутся из-за непомерно большого веса из-за непомерно тяжёлого рантайма (из-за bw-compat) который приходится с собой тягать.

ну и сколько клиентам на дорогом мобильном интернете будет стоить эта обратная совместимость?

простецкая страничка нынче легко выжирает пару мегабайт трафика, так что аргумент спорный

И что? Почему вы вдруг решили что версию фреймворка обязательно нужно обновлять?

Преимущества есть, так как другие разработчики их видят. Я их вижу, мои коллеги их видят, тут в теме есть люди, которые их видят.

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

Представьте, что землекоп с лопатой говорит экскаваторщику, что экскаваторы это очень сложно — куча моделей их, выпускают каждый год новую, не угнаться за этим и вообще на кой эти экскаваторы нужны (у них никаких преимуществ), если есть лопата и она отлично справляется. Только землекоп с лопатой не понимает, что ему нужно копать простые траншеи, а экскаваторщик роет котлованы под строительство больших сооружений.

Если б писали на Angular, а не Vue, возможно мнение было бы другим.

Я не вижу критического влияния какого-то одного фреймворка на вопрос «сложности» технологий в целом.

Влияние в том, что конкретная команда пишет на каком-то конкретном фреймворке, и они смотрят на все фреймворки через призму одного. Никто не говорит, что moment.js «сложен», это огромная либа, но большинству нужно знать API из 2 методов.
А вот фреймворки, могут быть сложными, особенно когда вводят тонну абстракций, не свойственных веб-приложениям в целом. Тоесть Vue не «сложен», и если что-то идёт не так, его исходники довольно легко читаются в отличии от Angular2.

это огромная либа, но большинству нужно знать API из 2 методов

Вот именно. То есть сложности нет никакой, о которой нам пытаются тут рассказать.
Есть задача сделать SPA — бери фреймворк, который знаешь и пиши на нём. Если тебе навязывают фреймворк, который ты не знаешь... ну это же не проблема сложности технологий, верно? Это проблема навязывания, по какой-либо причине, того, что вы не знаете, и что вам придётся учить.

Вы сейчас пытаетесь тему разговора свести к сложности Ангуляра, хотя изначально разговор не об этом шёл вообще-то.
И я, конечно, только пару уроков по Ангуляру смотрел, но ничего сложного пока там не нашёл.

Тут смотря как на «сложность» смотреть, если так сказать дискретно, типа вот сел типок за клавиатуру задачу делать, день сидел, два сидел и не смог сделать (false), или сделал (true).
Если, например, на одном фреймворке, задача занимает 150 строк кода, а на другом 2 строки, то там где 150 кажется реально сложными, хотя большинство строк простые, но писать это сложно.

Когда в одном фреймворке, есть 1000 интерфейсов, создающих абстракции, которые сложнее в разы, чем вещи под их капотом, а в другом этого просто нет, то да — это сложно в одном и просто в другом.

Либо есть варианты, в стиле когда к тебе приходят и говорят: а сделайте ка, чтобы у нас был билд 100 kb первоначальный, а потом lazy шло, и вот на одном фреймворке, ты такой «тю, да легко», а на другом писец сложно, а скорее не возможно, и ты такой «нет, Вам это не нужно». Тут и про холодный старт 200 ms.

И чтобы билд билдился не минуту, сложно ли чтоб билд билдился минуту, для нервов — сложно.

Ну и сколько примеров таких изменений во фреймворках вы способны озвучить?

Обычно это голословные заявления, которые основаны на мифах и шутейках, и первое что приводят в качестве аргумента — Angular.js / Angular, что вообще не катит как таковой.

Очевидно ошибался.

До 2011 ты был прав. После — нет.
Плюсы наконец-то начали развиваться, и то, как у них это происходит, не так и плохо.

Но думаю с таким персонажем как ты продолжать диалог бессмысленно

Тебе — безусловно.

Услышали, теперь ответьте

То есть единственным вашим примером был Angular.js / Angular ? Ну ок, очень констуктивно пообщались, спасибо))

Всё понятно. Спасибо за разъяснение

Недавно мой заказчик начитавшись инета решил блеснуть умом и сказал заменить таблицы на сайте на Datatable мол там же уже есть и пагинация и сортировка и экспорт ничего не надо програмировать.

И вы согласились? И не попытались объяснить заказчику что идея говно?

если человек не способен в таком разобраться, он или даже не пробует это делать, или дебил

Жестко, но метко

Люди постояно переливают из пустого в порожнее переписывают системы.

Я переписывал потому что nosql сервак не справлялся с выборкой данных. Там система логистики складов где некоторые репорты даже mssql ложат — приходится делать денормализацию и прочее.
hfphf,s ljvfkb xnj jyb cajhvbhe.n byajqcs b jhlthf d оыщт yf rkbtynt засунут его в CouchDB где json это как раз формат хранения там же будет делать выборки встроеным яваскрптом и все будет в шокопаде. Шоколад закончился после месяца работы складов на первом же серьезном репорте по аналитике
В этом и проблема — в описаниях в инете все выглядит класно — вот вам фронтенд и бекнд на яваскрипте ничего больше учить не надо — обмен данными в json вот вам Nosql с ключ значение никакого дремучего SQl. Новичкии, особенно те кто прищел в IT потому что тут хорошо платят а не потому что у него есть хоть какие то способности, на это подседают пишут проекты потом проекты проекты оказываются более трудоескими но куда уже деватся, нанимаются новые фронтэндщики и т.д. К меня ра работе проект на реактие я один на бекенде клепаю им API почти копипастом а на фронтенде 3 человека. Если бы регал я а не «продвинутый» прожектманагер — вместо трех на фронтэенде сидел бы только верстальщик

В этом и проблема — в описаниях в инете все выглядит класно — вот вам фронтенд и бекнд на яваскрипте ничего больше учить не надо — обмен данными в json вот вам Nosql с ключ значение никакого дремучего SQl.

Ну голову-то надо включать, а библиотеки для работы с реляционными БД есть.

Новичкии, особенно те кто прищел в IT потому что тут хорошо платят а не потому что у него есть хоть какие то способности, на это подседают пишут проекты

Они по-хорошему сами не должны писать проекты.

К меня ра работе проект на реактие я один на бекенде клепаю им API почти копипастом а на фронтенде 3 человека.

И? Это либо сложный фронт с простым бэком, либо менеджер-дурак. При чем здесь технологии?

Если бы регал я а не «продвинутый» прожектманагер — вместо трех на фронтэенде сидел бы только верстальщик

И че бы он наверстал? Неповоротливое нечто в стиле 90х? Или вы там огромной командой блог пишете в виде SPA?

Вы попробуйте взять дизайн этого проекта и самому сделать фронт, используя только jQuery. Потом приходите и расскажите о своём опыте.

Работаю несколько лет только с Ember.js, что я делаю не так? Ну кроме того что не вписываюсь во все вакансии, но мне во все и не нужно.

Не знаю ни одного фронтендщика, который бы гонялся за новым фреймворком. Все сидят на тех фреймворках, которые им нравятся: React, Angular, Vue.

Про постоянную погоню пишут обычно бэк-разработчики, которые не трогали фронт 10 лет, начитаются подобных тупых комментариев или шутеек, и не в курсе того как Angular относится к версионированию. То есть далёкие от фронта люди.

И такие люди «с практическим складом ума» даже не задумываются о том, что современные фреймворки во многом ещё и ответ на новые вызовы UX-дизайна. О дизайне такие люди не задумываются в принципе и считают, что как было в 90-х всё «легко» и «красиво», так оно и осталось.

1. Повышается порог вхождения, что автоматически отметает детей от ИТ

Вот ты щас сам и ответил на вопрос когда васм станет мейнстримом. Ответ никогда, потому что повышение порога вхождение ради самого порога вхождения идет вразрез с интересами бизнеса.

Конечно становятся, кто ж спорит — когда возросшая сложность задач заставляет (или уперлись в ограничения старого тулинга, что в общем одно и то же). Но новые более сложные инструменты не становятся менйстримом ни по приколу, ни чтобы ЧСВ почесать, ни чтобы «отмести детей от айти»...

WebAssembly, смотря на Blazor (Client и Server), довольно скоро дропнет многие frontend команды.

Если в деталях, то с начала 2000-х enterprise искал пути сделать front быстро работающим и одновременно не писать js.
Первые попытки этого были в ASP.NET AJAX UpdatePanels и других подобных IndirectAJAX реализациях, Silverlight как один из ответов, GWT, VWG.
Все эти решения были далеко не идеальны, и поэтому они сдались и начали использовать JS фреймворки, дававшие более качественный UI. Но на самом деле все эти лет 13 им был нужен серверный Blazor. Это новая реинкарнация UpdatePanels, то как оно должно быть.

Так ведь JS не нужен.

Так и фронт не нужен.

человек выучил бы grunt а тут уже грунт ацтой есть гораздо более крутой Gulp

А зачем учить что-либо из них, кроме как ради баззвордов в резюме и объявлениях? Я grunt вообще не знаю, gulp использовал пару раз и ничего там не учил. Чтобы написать конфиг достаточно документации и статей в интернете, это всё гуглится на раз. И не забыть в корень положить README.md, в котором указать как это запустить. Всё.

Вот тренд баззвордов в резюме и джоб постингах мне абсолютно не нравится. Доходит до того что там можно встретить git. Зачем туда пихать утилиты, которые осваиваются за полдня, я хз.

В TFS ще класно було мати build server і запускати збірки прямо зі Студії. Але цим мало хто користувався.

Нафига мощный гит

В гите главное не что мощный, а что распределённый.
Делал работу, каждые 3 минуты фиксировал полученное, если нравится, и откатывал, если не нравится, потом пересобрал историю в логически связные коммиты и отдал коллегам или просто напрямую в основную репу.
Реально больше никто так не умеет, всё сплошь костыли.
А централизованное дерьмо вроде CVS или SVN — вообще чихнуть нельзя, чтобы не внести какую-то кривую тошнотворную ерунду, по которой ещё 20 лет потом будут вспоминать, какой ты дурак и какое у тебя хреновое настроение было в этот день.

SVN — вообще кусок полного лайна. CVS и то был лучше, там не пытались покрыть шоколадом то, что покрывать не надо. CVS — простой понятный стимпанк. SVN — покрасили краской, а ржавчина тут же стала проступать на каждом углу и краска пошла отваливаться. Я несколько раз пытался перейти с CVS на SVN, плевался и возвращался. На Git — перешёл быстро и легко.

Чтобы полезный результат не испортить.
Ну, может, не 3, а даже 10. Главное, что есть локальная история, которая не для экспорта, и есть экспортная, которая уже логически завершена.

Разный. Может быть полезный, может вредный.

Зачем его портить?

Не зачем, а почему.

Написал кусок кода, а затем решил его непоправимо улучшить. Оказалось, ошибся. Значит, откатился назад и пошёл дальше экспериментировать.

Да и что можно написать за 3 минуты?

Иногда — очень много чего.

А никто от тебя и не требует.
Но это только один вариант вкусных возможностей. Другой — когда по результатам ревью легко и просто подправляешь какие-то мелочи в коммитах и перевыкатываешь (один коммит или цепочку).
И пробная цепочка показывается теми же методами, что и постоянные коммиты.
В разных костыльных поделках вроде SVN ты такого не сделаешь: или отдельной тулзой послал на ревью (мы таким страдали, было что-то от Atlassian), или закоммитил уже навечно и получаешь тумаков.

скидваешь «полку» коллегам

Зачем отдельная сущность «полки»?
И почему ты всё время говоришь про один коммит? Может, мне сейчас нужно 20 в цепочке?

А главное что когда делают ревью могут накатить твою «полку» у себя локально и даже подебажить у себя и потом отправить тебе фидбэк, и при этом никто не срет в свою хистори.

В Git точно так же. Вытянул себе состояние по голове цепочки коммитов и работаешь с ним.

При этои у тебя не просто два уродских ошока «было» и «стало»

Что такое «ошок»?
И тут полноценный коммит, или цепочка коммитов.

А хто не вміє перемикатись між бранчами? CVS?

идея умет локал хистори из коробки без каких либо гитов и прочего.

Ну то есть они сделали свой закат солнца вручную? Я ценю их настойчивость, но что они решали?

И обрати внимание, что в случае Git эта самая локальность истории это всего лишь вариант использования. Я могу все эти «progress!» и «ааа! мои руки!», если надо, скинуть в Gerrit (например, задачу аварийно передали другому, и ему надо всего лишь красиво оформить уже сделанное), pull request на github, gitlab или что там сегодня в моде, работать в другой IDE или вообще без IDE, если не хочется или невозможно... они ничем не отличаются от «постоянных» коммитов. Зато их точно так же можно переразобрать и собрать во что-то в другом виде.

А ещё есть «индекс» и возможность аккуратно гранулированно его набирать — и без этого, конечно, можно работать, но это будет или в 10 раз больше усилий, или тотальная грязь в репозитории.

Реальная полезность гита, это переключение между бранчами — переключение между тасками без вреда друг для друга, но это используеться в 5 % случаев.

Вот это как раз ничем не выделяется на фоне аналогов. Или ты с чем-то совсем странным сравниваешь?

Local history это за другое, а 20 коммитов чтоб показать коллегам что, для чего и в какой последовательности ты делал.

даже сырого картофеля

это уже за гранью

сок огурца

ингредиент номер один для освежающего летнего напитка

В Беларуси или где там петрушка считается наркотиком.
Делает каменный стояк, а если перебрать, то и до глюков не далеко.

В TFS есть такая штука как «полка» shelf, это комит который можно отправить коллеге, можно сохранить, можно откатить и накатить его

Ну и зачем его логически отделять в отдельную сущность?

А главное не надо дрочиться в консоль с магическими переменными слепливая комиты в один.

Никаких магических переменных, всё банально. А слепливание или, наоборот, расщепление — для того, чтобы получить осмысленную картину.

а потом когда ревьювают то оно комиты новые из дева(те что накомитали в дев пока я в своей ветке сидел) показывает как мои

Как это ты такого добился?
Само оно так не получается, это я даже не знаю, куда копать, чтобы такое получить.

вот нахера такое делать?

Не знаю. Это ж ты получил, у себя и спрашивай...

Нет, мы пришли к тому, что кое-кто просто решил свалить на Git всех собак...
по начальному описанию, тут вообще участвовала какая-то левая тулза. Вот с ней и разбирайся.

Пан не знає різниці між merge й rebase? Не знає що це два різні інструменти під різні задачі? Чи не вміє ними користуватись?
Ну тоді то так звичайно — шайтан-гіт винен.

Именно _переменных_?
Перейди на стандартную терминологию, если хочешь, чтобы тебя поняли.

Где тут хоть одна переменная, которую надо выставлять?

Ключи, не?

Это опции.
Переменные это если бы надо было писать что-то вроде export GIT_ZUKA=M22, или столь же магические значения в самих командах.

Ну а если вы не хотите учить опции (причём самые стандартные), ну, вперёд гуй-клиенты применять. Там всё то же самое галочками с описаниями. Вполне почтенное желание и реализуется реальными софтинами.

Теперь ты вдруг решил подключить сюда проблемы левых кривых клиентов?

Так недавно было когда вдруг решили отказаться от https на гите

Git не отказывался от https. Ты опять про какие-то левые тулзы? Прекращай курить шишки.

Как можно менять сам гит?

Не, твои шишки таки слишком смолистые. Что значит «менять сам гит», откуда ты это взял?

НА проекте нашем убрали.

Ну и почему остальные виноваты, что на вашем проекте кто-то решил отказаться от https?

Ога левые клиенты, а они есть какие-то официальные у гита?

Да. Те что поступают c git-scm.com.

Гитхаб десктоп, сорс три, вот что у меня на компе.

Ну и кто из них налажал? И покажи STR. Я на 90% уверен, что пока ты будешь его записывать, поймёшь сам, что сделал не так. Но если воспроизводится — ты найдёшь, куда слать PR.
Мне лично проблемы обоих как-то слабо интересны.

Ну вот ты и сам доказал что гит это 100500 спообово острелить себе ногу

У тебя логика типа «Windows это 100500 способов отстрелить себе ногу, вот берём диск „300 лучших программ“ с Петровки и запускаем под администратором — смотрите, сколько вирусов появилось!»

Ну, продолжай гиту приписывать проблемы левых клиентов...

Окуенная тула, ппц просто.

Да, окуенная. В хорошем смысле. Но куда понять тому, кто с нормальной логикой не в дружбе...

а не создавать новые способы

Не вопрос. Закажи Apple единственный нормальный VCS... ой, а почему это Apple в основном использует сейчас Git? Ой беда-то какая...