Хм, а ведь в этом есть доля истины. Это же и к нам можно применить, верно?)
Там какая суть: в одном варианте процессор просто исполнял бинарник, а в другом также исполнял этот бинарник, но уже тратил часть времени на анализ и оптимизации этого же бинарника.
Как итог суммарный выигрыш от оптимизации покрыл все расходы на анализ и эмуляцию, да ещё накинул сверху 20% производительности.
Если отсюда убрать эмуляцию - выигрыш от оптимизации явно будет ещё выше, поскольку эмуляция на старом железе была дорогим удовольствием по времени. Современных технологий виртуализации тогда не было.
Но этот принцип можно использовать и для нашего мозга: что если не выполнять интеллектуальную работу, а сперва проанализировать её и оптимизировать?
В большинстве случаев затраты времени на анализ окупятся сэкономленным оптимизацией времени.
А что касается рекурсии - это работать определенно не будет.
Первый раунд оптимизации уже выявил всё, что могли выявить те алгоритмы.
Второй раунд будет уже оптимизировать исключительно сам слой эмуляции. Но его оптимизировать смысла нет - выгоднее эмуляцию просто исключить из процесса. Современный софт так и собирается: основной набор оптимизаций проводится во время генерации программного кода бинарника, и это довольно тяжёлый по ресурсам процесс, а значит явно эффективнее jit, который не может себе позволить так тщательно анализировать код.
Тоже размышлял о подобном, но к сожалению так и не поставил для себя точку в этом вопросе.
Какой-то смысл в этом есть, нечто сакральное общее для всего мира. Но какой именно — решительно непонятно. Тут что-то такое, что ускользает, когда о нем думаешь.
Например общеизвестно что энтропия в природе со временем нарастает, это наблюдается везде.
Но там, где есть жизнь, наблюдается обратное. Жизнь организует хаос, снижает энтропию вокруг себя. Жизнь и хаос в природе несовместимы, это два противоположных полюса.
Они каким-то образом связаны, это факт. Но как и почему — неизвестно.
Что любопытно, такими свойствами обладают и кристаллы, но они явно не живые. Куда их приткнуть — тоже непонятно.
И что всё это в итоге означает — тоже непонятно. Может жизнь так просто получает энергию. Может вынуждена отвоевывать себе пространство, очищая его от смертоносной энтропии.
Единственное что сюда явно не вписывается — кристаллы. Не особо понятно что у них общего с жизнью, и почему они связаны с энтропией теми же отношениями, что и жизнь.
Наверное проще о таких сущностях просто не думать. Возможно у нас пока недостаточно информации, чтобы с этим разобраться.
Но как минимум способность упорядочивать хаос — это основное свойство любой жизни. Судя по наблюдениям автора, эта способность востребована и при работе с информацией — её совершенствование оценивается бизнесом положительно и вознаграждается.
Так давно существует отличная обучающая среда pascal ABC. Кажется даже с неким подобием IDE. И оно похоже еще живое: pascalabc.net
Т.е. и на паскале вполне себе удобно можно жить.
Ну а далее все стандартно: C/Cpp, java, и понеслась. Там дальше уже алгоритмы рулят, а не конкретный язык. Конкретный язык каждый уже под себя и свои задачи выбирает.
И ещё хорошо бы параллельно заглянуть в мир ассемблера, почитать «Код — тайный язык информатики» (https://habr.com/ru/post/68365/)
Это наиболее лучшее описание сути веб-технологий из того, что я встречал.
И диаграмма обработки запроса шикарна: тут и шаблонизация, и mvc, и роутинг, и работа сервера.
Хотелось бы посмотреть на более идеальное описание, если у вас есть такая ссылочка.
А можете привести ссылочку на такую статистику?
Пока удалось нагуглить только статистику w3tech, где у java всего 3.5%
И это при том что почти половина java-разработчиков в опросе jetbrains заявила что используют java для веб-сервисов.
Не могу понять в чем причина: либо java-разработчиков мало, и эта половина и покрывает те 3.5%, либо где-то лежит огромный невидимый пласт веб-сервисов, которые покрывают половину интернета, но никак не учитываются в статистиках.
Пиццу не сам делаешь, значит можно делегировать наемным рабочим. К тому же, конкретно с пиццей, почти все там сейчас заказное и продается в готовом виде ведрами, только собирай как конструктор, для чего много ума не требуется.
Найти ребят на сделку, т.е. они сами себе зарплату заработают.
Найти того кто присмотрит за ними и обучит — опытный персонал есть, кто-то из них за небольшой бонус к зарплате с удовольствием выступит в роли шеф-повара для новых ребят. Можно значительно усилить мотивацию перспективой должности с повышенным окладом, при условии что новая команда окупит себя — так, чисто чтобы ваши интересы совпадали.
Помещение и оборудование сейчас многие предлагают в аренду — решается такое за нескольких дней.
Для усиления эффекта оповестить город — это тоже не обязательно дорого, если подумать самому, а не покупать продвижение у всяких левых контор, которые регулярно всем названивают и выдаю откровенную дичь.
Вложиться в аренду, хотя бы на пару месяцев, и посмотреть что выйдет.
Потери в этом случае минимальны, вложения небольшие, зато есть хороший шанс потеснить конкурентов, у которых на такой финт просто нет ресурсов, т.к. для них вложения хотя бы на сравнимый уровень получаются значительно выше.
Даже если не получится — теряешь немного. Да и конкуренты наверняка не оставят такое без внимание и попробуют повторить, что ослабит их, т.к. для них такая попытка стоит значительнее дороже.
Т.е. считай что при небольших затратах имеешь значительный выигрыш в двух случаях из трех — а это просто невероятные шансы в бизнесе, где счет идет на единицы процентов.
Не избыточно, наоборот — грамотно построенный код легче поддерживать и модифицировать.
Фреймворк уже предоставляет все необходимые инструменты для расширения — только воспользуйся. И стоит ничего: несколько строчек в конфигах, никаких лицензий и абонплат.
Без фреймворка аналогичный уровень функционал придется писать с нуля самому, а это многие часы времени впустую, которые кто-то должен оплачивать.
И без фреймворка дорого вносить какие-то кардинальные изменения в функционал: при прочих равных, если бизнес запросит что-то сильно отличающееся от того, что есть сейчас, без фреймворка такие изменения обойдутся гораздо дороже. Фреймворки как раз заточены под изменчивость и расширяемость.
А с точки зрения программиста, фреймворк позволяет реализовать тот же функционал за гораздо меньшее время: вместо реализации с нуля программист подключает фреймворк и получает гарантированно работающий и богатый функционал, с ним он может сосредоточиться непосредственно только на самом сайте, не отвлекаясь на всякие базовые вещи, типа обслуживания форм, работы с БД, и прочее.
При всем этом код еще и оказывается стандартизирован: любой другой программист, знающих этот фреймворк, может поддерживать код. Чего не скажешь о самописном коде, львиная доля времени с которым уйдет просто на то, чтобы понять как он устроен, какие ограничения имеет, и на борьбу со скрытыми ошибками: так оно работает, а так внезапно уже нет, а причина — кто-то где-то глубоко внутри кода поленился сделать нормально какой-то маленький участок кода, который сперва предстоит найти аки иголку в стоге сена.
Проблема тут в другом — видимо местный рынок просто не развит, если даже просто человек знающий фреймворк кажется чем-то исключительным и стоит дорого.
В реалиях мира айти фреймворки — это просто базовый уровень, этим никого не удивить, это просто стандарт.
Это прекрасно. Но среди тех мелких предпринимателей, что наблюдаю вокруг, очень мало толковых. И это огромная возможность для толковых людей…
Типичный образ: поперло — отстроили бизнес, отдыхаем, закупаемся тачками/квартирами, волна спроса прошла — бегаем с горящей задницей без понятия что делать, продаем тачки/квартиры, экономим на зарплатах подчиненных.
На самом деле мало кто из них грамотно поддерживает свой бизнес или что-то там планирует. Когда есть прибыль — выкачивают её из бизнеса ради хорошей жизни, когда почти нет — экономят, выживают чудом.
Просто среднего ума человек, не расслабляясь как они, легко отберет у них весь рынок.
Конкуренция там уровня: сделаем цены ниже чем у конкурента, и будем гнать откровенный брак.
Создается впечатление что мелкий рынок по стране просто не развит: любая минимально качественная конкуренция просто выдавит всех этих предпринимателей с рынка.
Если ситуацию взять как у дрпасс, то скорее так: скачать программу, обнаружить что трансивер не работает, обновить прошивку, обнаружить что… трансивер не работает. Финита ля комедия: исходников нет, ничего не поправить, выбрасывай трансивер покупай новый, с шильдиком win10 pass.
Современные маховики при разрушении быстро гасят всю энергию о корпус. Именно поэтому они волокнистые, а не сплошные — то же углеволокно вместо чугуния.
Так что с этой стороны они достаточно безопасны.
Про литий такое сказать нельзя — в случае повреждения там начинается неконтролируемый лавинообразный процесс саморазогрева и выделения огромных количеств горючего газа.
Даже разделение ячеек не особо спасает, т.к. при повреждении нескольких ячеек сразу суммарная выделяемая тепловая мощность приводит к перегреву и взрыву даже разделенных соседних ячеек, что в итоге выливается в тот же самый лавинообразный процесс, но чуть более замедленный, и возникающий уже только при серьезных повреждениях, в которых разрушается как минимум группа ячеек. Но в автоавариях на больших скоростях повреждения почти всегда более чем серьезные.
Я понимаю, что здесь скрипт уровня «слепили на коленке за 5 минут», и ничего серьезного он в принципе не предусматривает. Большинство такое даже не публикует, т.к. это просто какие-то разовые решения.
Но если уж публикуешь код, не важно какого он уровня — без git это делать как минимум очень странно.
Без обид, но код без git не воспринимается даже минимально серьезно.
Потому что такой расклад гарантирует следующее:
-нулевой уровень поддержки. Автор вообще не заморачивается публикацией, и завтра-послезавтра о нем забудет.
-нулевую стабильность. Завтра автор изменит код и перезапишет архив, добавит новых ошибок, и никто с этим ничего не может сделать. Каждое новое скачивание несет в себе новую версию и новые сюрпризы, которые естественно никому не интересно разгребать.
-мертвый код. Трекера ошибок нет — сообщить об ошибке или выложить решение некуда. Хостинг для кода временный — завтра архив протухнет, послезавтра будет удален. Через 3 года наткнешься на ссылку, а она мертвая. И таких статей в сети с мертвыми ссылками — миллионы.
-проблемы с использованием. Даже если ты скачал код и самостоятельно его доработал, завтра автор выложит новую версию, не совместимую с твоей, и все твои наработки коту под хвост, а без git поиск расхождений и обновление кода — тот еще цирк. Да, можно тупо не качать новые версии, но что если там добавилась какая-то нужная фича?
Поэтому обязательно нужно завести аккаунт на github/gitlab, и публиковать свои решения через них.
И под каждый проект нужно делать отдельный репозиторий.
Только так может выйти хоть что-то
из подобных начинаний.
Да, многим кажется что все это фигня. Действительно — зачем какие-то лишние сервисы?
Но это ровно до того момента, как код захочет модифицировать кто-то другой.
Потому что в этом случае встает проблема синхронизации наработок нескольких человек.
И без git такую проблему разрешать крайне трудно и затратно. Уже после нескольких таких слияний захочется плюнуть на все это и забросить.
А git все это берет на себя, и настолько упрощает, что об этой проблеме практически забывают, вспоминая изредка при конфликтах, да и там это решается буквально за минуту.
Что касается отсутствия трекера ошибок — это вообще фатально.
Я сейчас пользую платным софтом, у которого несколько детских багов, которые устранить можно за пару часов, если о них станет известно разработчику. К сожалению этот софт разрабатывается на коленке, и не имеет трекера ошибок. А почта есть только менеджеров, которые работают через задницу, и не понимают в чем проблема. Поэтому эти баги уже пару лет там висят.
Для любого софта обязательно должен быть трекер ошибок, в котором пользователи как минимум могут сообщить о проблеме и описать её, а как максимум — предложить уже готовое решение или патч, облегчив жизнь для всех.
Зы не воспринимай это как критику. Это просто пояснение, почему стоит обязательно освоить git, если имеешь дело с кодом.
Хм, а ведь в этом есть доля истины. Это же и к нам можно применить, верно?)
Там какая суть: в одном варианте процессор просто исполнял бинарник, а в другом также исполнял этот бинарник, но уже тратил часть времени на анализ и оптимизации этого же бинарника.
Как итог суммарный выигрыш от оптимизации покрыл все расходы на анализ и эмуляцию, да ещё накинул сверху 20% производительности.
Если отсюда убрать эмуляцию - выигрыш от оптимизации явно будет ещё выше, поскольку эмуляция на старом железе была дорогим удовольствием по времени. Современных технологий виртуализации тогда не было.
Но этот принцип можно использовать и для нашего мозга: что если не выполнять интеллектуальную работу, а сперва проанализировать её и оптимизировать?
В большинстве случаев затраты времени на анализ окупятся сэкономленным оптимизацией времени.
А что касается рекурсии - это работать определенно не будет.
Первый раунд оптимизации уже выявил всё, что могли выявить те алгоритмы.
Второй раунд будет уже оптимизировать исключительно сам слой эмуляции. Но его оптимизировать смысла нет - выгоднее эмуляцию просто исключить из процесса. Современный софт так и собирается: основной набор оптимизаций проводится во время генерации программного кода бинарника, и это довольно тяжёлый по ресурсам процесс, а значит явно эффективнее jit, который не может себе позволить так тщательно анализировать код.
Какой-то смысл в этом есть, нечто сакральное общее для всего мира. Но какой именно — решительно непонятно. Тут что-то такое, что ускользает, когда о нем думаешь.
Например общеизвестно что энтропия в природе со временем нарастает, это наблюдается везде.
Но там, где есть жизнь, наблюдается обратное. Жизнь организует хаос, снижает энтропию вокруг себя. Жизнь и хаос в природе несовместимы, это два противоположных полюса.
Они каким-то образом связаны, это факт. Но как и почему — неизвестно.
Что любопытно, такими свойствами обладают и кристаллы, но они явно не живые. Куда их приткнуть — тоже непонятно.
И что всё это в итоге означает — тоже непонятно. Может жизнь так просто получает энергию. Может вынуждена отвоевывать себе пространство, очищая его от смертоносной энтропии.
Единственное что сюда явно не вписывается — кристаллы. Не особо понятно что у них общего с жизнью, и почему они связаны с энтропией теми же отношениями, что и жизнь.
Наверное проще о таких сущностях просто не думать. Возможно у нас пока недостаточно информации, чтобы с этим разобраться.
Но как минимум способность упорядочивать хаос — это основное свойство любой жизни. Судя по наблюдениям автора, эта способность востребована и при работе с информацией — её совершенствование оценивается бизнесом положительно и вознаграждается.
Он более строг, плюс, насколько помню, нужно иметь понятие о библиотеках и подключать их.
Т.е. и на паскале вполне себе удобно можно жить.
Ну а далее все стандартно: C/Cpp, java, и понеслась. Там дальше уже алгоритмы рулят, а не конкретный язык. Конкретный язык каждый уже под себя и свои задачи выбирает.
И ещё хорошо бы параллельно заглянуть в мир ассемблера, почитать «Код — тайный язык информатики» (https://habr.com/ru/post/68365/)
www.advgazeta.ru/ag-expert/advices/12-mln-moshenniki-pokhitili-so-schetov-moskvicha-posle-zameny-ego-sim-karty
www.car72.ru/forum/viewtopic.php?t=112420
medialeaks.ru/2301amv-beeline-money
И диаграмма обработки запроса шикарна: тут и шаблонизация, и mvc, и роутинг, и работа сервера.
Хотелось бы посмотреть на более идеальное описание, если у вас есть такая ссылочка.
Пока удалось нагуглить только статистику w3tech, где у java всего 3.5%
И это при том что почти половина java-разработчиков в опросе jetbrains заявила что используют java для веб-сервисов.
Не могу понять в чем причина: либо java-разработчиков мало, и эта половина и покрывает те 3.5%, либо где-то лежит огромный невидимый пласт веб-сервисов, которые покрывают половину интернета, но никак не учитываются в статистиках.
В спецификации допускаются кратковременные перегрузки в 200-300g
Пиццу не сам делаешь, значит можно делегировать наемным рабочим. К тому же, конкретно с пиццей, почти все там сейчас заказное и продается в готовом виде ведрами, только собирай как конструктор, для чего много ума не требуется.
Найти ребят на сделку, т.е. они сами себе зарплату заработают.
Найти того кто присмотрит за ними и обучит — опытный персонал есть, кто-то из них за небольшой бонус к зарплате с удовольствием выступит в роли шеф-повара для новых ребят. Можно значительно усилить мотивацию перспективой должности с повышенным окладом, при условии что новая команда окупит себя — так, чисто чтобы ваши интересы совпадали.
Помещение и оборудование сейчас многие предлагают в аренду — решается такое за нескольких дней.
Для усиления эффекта оповестить город — это тоже не обязательно дорого, если подумать самому, а не покупать продвижение у всяких левых контор, которые регулярно всем названивают и выдаю откровенную дичь.
Вложиться в аренду, хотя бы на пару месяцев, и посмотреть что выйдет.
Потери в этом случае минимальны, вложения небольшие, зато есть хороший шанс потеснить конкурентов, у которых на такой финт просто нет ресурсов, т.к. для них вложения хотя бы на сравнимый уровень получаются значительно выше.
Даже если не получится — теряешь немного. Да и конкуренты наверняка не оставят такое без внимание и попробуют повторить, что ослабит их, т.к. для них такая попытка стоит значительнее дороже.
Т.е. считай что при небольших затратах имеешь значительный выигрыш в двух случаях из трех — а это просто невероятные шансы в бизнесе, где счет идет на единицы процентов.
Фреймворк уже предоставляет все необходимые инструменты для расширения — только воспользуйся. И стоит ничего: несколько строчек в конфигах, никаких лицензий и абонплат.
Без фреймворка аналогичный уровень функционал придется писать с нуля самому, а это многие часы времени впустую, которые кто-то должен оплачивать.
И без фреймворка дорого вносить какие-то кардинальные изменения в функционал: при прочих равных, если бизнес запросит что-то сильно отличающееся от того, что есть сейчас, без фреймворка такие изменения обойдутся гораздо дороже. Фреймворки как раз заточены под изменчивость и расширяемость.
А с точки зрения программиста, фреймворк позволяет реализовать тот же функционал за гораздо меньшее время: вместо реализации с нуля программист подключает фреймворк и получает гарантированно работающий и богатый функционал, с ним он может сосредоточиться непосредственно только на самом сайте, не отвлекаясь на всякие базовые вещи, типа обслуживания форм, работы с БД, и прочее.
При всем этом код еще и оказывается стандартизирован: любой другой программист, знающих этот фреймворк, может поддерживать код. Чего не скажешь о самописном коде, львиная доля времени с которым уйдет просто на то, чтобы понять как он устроен, какие ограничения имеет, и на борьбу со скрытыми ошибками: так оно работает, а так внезапно уже нет, а причина — кто-то где-то глубоко внутри кода поленился сделать нормально какой-то маленький участок кода, который сперва предстоит найти аки иголку в стоге сена.
Проблема тут в другом — видимо местный рынок просто не развит, если даже просто человек знающий фреймворк кажется чем-то исключительным и стоит дорого.
В реалиях мира айти фреймворки — это просто базовый уровень, этим никого не удивить, это просто стандарт.
Типичный образ: поперло — отстроили бизнес, отдыхаем, закупаемся тачками/квартирами, волна спроса прошла — бегаем с горящей задницей без понятия что делать, продаем тачки/квартиры, экономим на зарплатах подчиненных.
На самом деле мало кто из них грамотно поддерживает свой бизнес или что-то там планирует. Когда есть прибыль — выкачивают её из бизнеса ради хорошей жизни, когда почти нет — экономят, выживают чудом.
Просто среднего ума человек, не расслабляясь как они, легко отберет у них весь рынок.
Конкуренция там уровня: сделаем цены ниже чем у конкурента, и будем гнать откровенный брак.
Создается впечатление что мелкий рынок по стране просто не развит: любая минимально качественная конкуренция просто выдавит всех этих предпринимателей с рынка.
Так что с этой стороны они достаточно безопасны.
Про литий такое сказать нельзя — в случае повреждения там начинается неконтролируемый лавинообразный процесс саморазогрева и выделения огромных количеств горючего газа.
Даже разделение ячеек не особо спасает, т.к. при повреждении нескольких ячеек сразу суммарная выделяемая тепловая мощность приводит к перегреву и взрыву даже разделенных соседних ячеек, что в итоге выливается в тот же самый лавинообразный процесс, но чуть более замедленный, и возникающий уже только при серьезных повреждениях, в которых разрушается как минимум группа ячеек. Но в автоавариях на больших скоростях повреждения почти всегда более чем серьезные.
Но если уж публикуешь код, не важно какого он уровня — без git это делать как минимум очень странно.
Без обид, но код без git не воспринимается даже минимально серьезно.
Потому что такой расклад гарантирует следующее:
-нулевой уровень поддержки. Автор вообще не заморачивается публикацией, и завтра-послезавтра о нем забудет.
-нулевую стабильность. Завтра автор изменит код и перезапишет архив, добавит новых ошибок, и никто с этим ничего не может сделать. Каждое новое скачивание несет в себе новую версию и новые сюрпризы, которые естественно никому не интересно разгребать.
-мертвый код. Трекера ошибок нет — сообщить об ошибке или выложить решение некуда. Хостинг для кода временный — завтра архив протухнет, послезавтра будет удален. Через 3 года наткнешься на ссылку, а она мертвая. И таких статей в сети с мертвыми ссылками — миллионы.
-проблемы с использованием. Даже если ты скачал код и самостоятельно его доработал, завтра автор выложит новую версию, не совместимую с твоей, и все твои наработки коту под хвост, а без git поиск расхождений и обновление кода — тот еще цирк. Да, можно тупо не качать новые версии, но что если там добавилась какая-то нужная фича?
Поэтому обязательно нужно завести аккаунт на github/gitlab, и публиковать свои решения через них.
И под каждый проект нужно делать отдельный репозиторий.
Только так может выйти хоть что-то
из подобных начинаний.
Да, многим кажется что все это фигня. Действительно — зачем какие-то лишние сервисы?
Но это ровно до того момента, как код захочет модифицировать кто-то другой.
Потому что в этом случае встает проблема синхронизации наработок нескольких человек.
И без git такую проблему разрешать крайне трудно и затратно. Уже после нескольких таких слияний захочется плюнуть на все это и забросить.
А git все это берет на себя, и настолько упрощает, что об этой проблеме практически забывают, вспоминая изредка при конфликтах, да и там это решается буквально за минуту.
Что касается отсутствия трекера ошибок — это вообще фатально.
Я сейчас пользую платным софтом, у которого несколько детских багов, которые устранить можно за пару часов, если о них станет известно разработчику. К сожалению этот софт разрабатывается на коленке, и не имеет трекера ошибок. А почта есть только менеджеров, которые работают через задницу, и не понимают в чем проблема. Поэтому эти баги уже пару лет там висят.
Для любого софта обязательно должен быть трекер ошибок, в котором пользователи как минимум могут сообщить о проблеме и описать её, а как максимум — предложить уже готовое решение или патч, облегчив жизнь для всех.
Зы не воспринимай это как критику. Это просто пояснение, почему стоит обязательно освоить git, если имеешь дело с кодом.
Так это озвучивали как одну из основных целей: рубить сеть на 100% при любой внешней угрозе.
Возможно, не возможно — никому не интересно. Сделают.
С камнями и палками
Если только мегаватт