Длинный и красивый рассказ о том, как озвучить всего 5-6 слов. Тут должна быть ссылка на статью "это можно было сделать без нейронных сетей"
Несколько лет назад Microsoft Research показывали описанный в статье трюк — генерацию голососа человека по образцу, только там они реально говорили длинными фразами, где хорошо слышна интонация
Строить сарай, делать деревянную мебель, самостоятельно ремонт в доме, варить металл, программировать в 20 лет… все эти вещи объединяет одно — быстрый, осязаемый результат. Вы что-то делаете своими руками и сразу видите, что получилось. Поэтому и от программирования глаза горят вначале, пока вы пишете маленькие простые программы.
А потом приходит понимание, что быстро можно сделать только мелкую поделку, большие вещи делаются большой командой в течение лет и часто работа отдельного человека размывается, не видно результат лично твоего труда.
Вот поэтому и начинает надоедать программировать в большой компании, на большом старом проекте. Я уверен, что точно также надоест заниматься сваркой, если нужно будет это делать каждый день, причём гораздо быстрее, чем программировать, потому что это тяжёлое дело.
Я лично за 20 лет карьеры программиста имел целую кучу хобби параллельно с работой, чтобы разбавить рутину. Это отлично помогает продолжать делать большую и долгую работу.
А уж какое хобби не особенно важно, в том числе было и несколько программных пет проектов и я с удовольствием садился их кодить вечером после основной работы. А также варил металл, делал мебель, запускал р/у модели, гонял на мотоциклах — много чего.
Просто не надо циклиться на чём то одном и считать, что 100% времени нужно заниматься этим
Есть разная справедливость, можно смотреть так: мы платим всем одинаковую сумму в долларах, а кто где живёт нам всё равно. Но тогда получится, что есть серьёзный градиент в фактическом уровне жизни, ведь в Нью-Йорке жить гораздо дороже, чем в деревне в Колорадо или в Тульской области и люди, которые виноваты только в том, что родились в большом городе и хотят там жить дальше, будут иметь в разы меньше свободных денег, чем живущие в деревне.
А можно платить так, чтобы в любом регионе у человека оставалось примерно столько же свободных денег после основных расходов. Да в Нью-Йорке дорого снимать квартиру, платить за метро и так далее, поэтому там мы повысим зарплату, чтобы на руках оставалось такая же 1000$ как у человека из Тулы.
На мой взгляд это довольно справедливо.
Такая мотивация предлагает: работай лучше, делай больше и получишь доход больше. А не "вали из NY в деревню и там сможешь сидя на заднице, ничего не делая получать тысячи баксов"
Сам по себе AnLinux ничего не делает, это просто ланчер, который говорит Termux какие пакеты поставить. Termux неплохо много чего умеет, но он использует какие-то свои репозитарии и чуть более сложные программы в нём не работают или работают плохо, также там есть отсавание по версиям.
Есть замечательный проект, который решает все эти проблемы: https://userland.tech/
Он позволяет запустить в Proot контейнере несколько полноценных версий линукса: Ubuntu, Debian, Alpine. Конечно ограчения контейнера всё равно где-то заметны, но количество софта, которое нормально работает гораздо больше, чем под Termux. Например я могу выкачать свой репозитарий с Angular 10 фронтом и .net core 3.1 backend, собрать всё и запустить прямо на телефоне. Причём работает всё вполне с разумной скоростью, долго только пакеты выкачиваются первый раз. Также успешно запускается MariaDB, Mongo вроде пробовал, но не помню результат. Есть доступ по SSH из сети, то есть вы можете сделать свой реальный сервер на телефоне, только придётся поковыряться в настройках экономии энергии, чтобы телефон не убивал контейнер.
Вопрос "зачем?" задавать не вижу смысла, любому гику понравится идея запустить полноценный веб хостинг прямо на телефоне — это же весело :)
В SQL базах тоже проблем хватает. Вот мы настроили версионирование через миграции, даже вроде внимательно пишем Down миграции и вот налили что-то в прод и поняли, что не то и надо откатить… В 90% случаев такая история заканчивается восстановлением из бекапа и кучей ночной работы :(
Я в 2012-2013 плотно работал с монгой в качестве быстрого кэша перед MS SQL, на тот момент в среднем раз в неделю один из 12 шардов умирал без явных причин. Т.к. это был кэш, не было проблемы его переинициализировать, но как единственную базу данных я бы монгу не стал использовать.
У вас бывали подобные проблемы? Как решили?
Вот, именно это я выше описал. Это ад, при хоть сколько-нибудь большом проекте.
Потому что вся работа с базой завязана на одно узкое место: команду dba.
Ладно бы, если вас было несколько десятков, но dba в всегда один и он ничего не успевает.
А ещё высшие степени вроде "вся, каждый" и так далее намекает на далекость от реального мира промышленной разработки :)) всё то каждый не окупается, всегда должен быть баланс между затратами и выхлопом, чтобы бизнес деньги заработал
А если у меня все данные не помещаются на один сервер?
Или если процессорных мощностей одного сервера не хватает?
А если у меня приложение должно работать в 30 региональных экземплярах расположенных по всему миру?
Оказывается, что база данных никаким образом не может хранить и энфорсить всю бизнес логику моего приложения. Значит, мне придется либо часть логики класть в базу, а часть оставлять в "фронтенде", либо уже сдаться и использовать базу просто как коробочку для строк. К тому же таких коробочек у меня десятки в каждом экземпляре приложения. А всю логику поддержания целостности данных реализовать снаружи. Более того, по мере развития моего приложения, я могу менять выбор базы данных, мигрировать на другие движки, которые например дешевле. Ведь платить за работу 200 баз данных довольно дорого и если я сэкономлю 20% миграцией на другой движок, руководство это вполне одобрит.
Но это конечно специфический пример, просто, чтобы показать, что не всегда можно всю бизнес логику положить в базу. Мы же тут собрались как писатели глобальных стартапов на миллиарды пользователей? :))
А не надо их там хранить. Вы же не храните все свои логи в виде сырых текстовых файлов?
Так и тут, пишите в табличку с датой в названии, а сборщик логов считает, отправит в хранилище, а табличку удалит
По поводу кривых запросов из orm, в целом согласен, кроме самых простых вещей, генератор запросов в тех орм, что приходилось использовать никуда не годится. Очень легко получить N+1, даже в простом случае. На любых более менее крупных проектах, мы используем только материализатор, а запросы пишем сами. Конкретно на шарпе используем Dapper — мне лично больше не нужно
Вы описываете мир, где интеграция нескольких приложений/проектов идёт через базу данных.
Я в таком мире жил некоторое время, очень неприятное место.
Все таблицы скрыты от простых юзеров, доступ на чтение через view, на запись через хранимки. Иначе ведь нельзя ничего менять в структуре, а то разные приложения будут ломаться. С разным релиз циклом.
Любые изменения — это большое трудное ревью.
И всё это в pl/sql, который реально хорошо знает 3 человека, а java знают тысячи.
На мой взгляд более эффективно закрывать базы данных с помощью rest api. Потому что в ресте хорошо проработана версионность и можно поддерживать разные версии апи, так что клиенты не будут знать о том, что внутри что-то поменялось, может мы вообще ушли с сиквела на Mongo. Апи остался тем же. Также код самого апи довольно прямолинейный и может быть написан на популярном языке с развитыми тулами, вроде той же java, c#, typescript.
При этом никто не запрещает делать тонкие оптимизации, там где они нужны. Профилируйте, ищите узкие места, переносите код в хранимки. Но пожалуйста, не делайте интеграцию через базу данных!
Я проводил подобное исследование для своего проекта, в итоге мы перешли с newtonsoft на system text.json, а остальное не стали использовать.
Дело в том, что очень значительный выигрыш производительности получается от строгости парсера. Что utf8json, что system text по умолчанию парсят только полностью валидный json да ещё case sensitive. Это конечно быстрее, но в глобальном апи сервисе, где люди часто для тестирования отправляют запросы руками через postman, а потом эти же строки вставляют в свой код, уже нельзя подходить с такой строгостью. Мы поняли, что мы сломаем колоссальное количество клиентов, если включим case sensitive и полную валидацию (например двойные кавычки, а не одинарные) и тп. Newtonsoft всё пропускает и куча клиентов, к сожалению этим уже пользуются. Так что мы перешли на system text, с настройками максимально близкими к newtonsoft и пока живём так. Надо ещё учитывать, что хотя utf8json правда парсит в 4 раза быстрее, общая цена парсинга в нашем запросе около 5%, то есть мы не можем так уж много выиграть даже от 100% оптимизации
А ещё вот это весь flux/redux…
На мой взгляд flux пытается таким заковыристым способом решить проблему отсутствия типизации. Если создавать модели со строгой типизацией, то смысл flux ускользает
Писать бекенд на nodejs с JavaScript вместо Шарпа, добровольно?
Похоже совсем сильно выгорели :)))
Я много писал на классическом .net, в том числе несколько лет на wpf — это было тёмное время ')
А потом перешёл на .net core web api + angular 2 и старше, также много бекенда на java + spring делал. В итоге мне доставляет большое удовольствие писать бекенд на net core, а фронт на ангуляр 10.
Терпеть не могу чистый JavaScript и стараюсь никак его не касаться
Количество, которое вы называете никак не нагрузит базу данных. Список на миллион доменных имён или транзакций занимает пару десятков мегабайт памяти и легко помещается в кэш, с ним limit и offset прекрасно сработают. В статье упоминается Фейсбук и другие гиганты и я бы предполагал размер таблиц изменяющийся хотя бы десятками гигабайт. Такую таблицу реально не имеет никакого смысла отображать в гуе с полной пагинацией. Это как если бы Гугл позволял посмотреть результаты поиска вплоть до 100млн.
Так что я поддерживаю NoRegrets, на таких больших данных работают фильтры + limit без пагинации. Но бывает реально трудно это объяснить пользователям, которые по старинке хотят "а можно всё посмотреть?"
Почему же редко используете? На мой взгляд как раз логично во всех запросах всегда задавать top или limit, равный максимальному разумному числу строк, которые мы ожидаем получить. Чтобы не случилось, что из-за бага в коде фильтрации, мы случайно попросил у базы 100500000 записей, перегрузили и базу и бекенд при этом
Десктопный Линукс это миф :) его никогда и не было и не будет. Потому что Линукс пишут фанаты консоли и unix way им самим не нужен удобный визуальный интерфейс как для простых смертных
Длинный и красивый рассказ о том, как озвучить всего 5-6 слов.
Тут должна быть ссылка на статью "это можно было сделать без нейронных сетей"
Несколько лет назад Microsoft Research показывали описанный в статье трюк — генерацию голососа человека по образцу, только там они реально говорили длинными фразами, где хорошо слышна интонация
Строить сарай, делать деревянную мебель, самостоятельно ремонт в доме, варить металл, программировать в 20 лет… все эти вещи объединяет одно — быстрый, осязаемый результат. Вы что-то делаете своими руками и сразу видите, что получилось. Поэтому и от программирования глаза горят вначале, пока вы пишете маленькие простые программы.
А потом приходит понимание, что быстро можно сделать только мелкую поделку, большие вещи делаются большой командой в течение лет и часто работа отдельного человека размывается, не видно результат лично твоего труда.
Вот поэтому и начинает надоедать программировать в большой компании, на большом старом проекте. Я уверен, что точно также надоест заниматься сваркой, если нужно будет это делать каждый день, причём гораздо быстрее, чем программировать, потому что это тяжёлое дело.
Я лично за 20 лет карьеры программиста имел целую кучу хобби параллельно с работой, чтобы разбавить рутину. Это отлично помогает продолжать делать большую и долгую работу.
А уж какое хобби не особенно важно, в том числе было и несколько программных пет проектов и я с удовольствием садился их кодить вечером после основной работы. А также варил металл, делал мебель, запускал р/у модели, гонял на мотоциклах — много чего.
Просто не надо циклиться на чём то одном и считать, что 100% времени нужно заниматься этим
Есть разная справедливость, можно смотреть так: мы платим всем одинаковую сумму в долларах, а кто где живёт нам всё равно. Но тогда получится, что есть серьёзный градиент в фактическом уровне жизни, ведь в Нью-Йорке жить гораздо дороже, чем в деревне в Колорадо или в Тульской области и люди, которые виноваты только в том, что родились в большом городе и хотят там жить дальше, будут иметь в разы меньше свободных денег, чем живущие в деревне.
А можно платить так, чтобы в любом регионе у человека оставалось примерно столько же свободных денег после основных расходов. Да в Нью-Йорке дорого снимать квартиру, платить за метро и так далее, поэтому там мы повысим зарплату, чтобы на руках оставалось такая же 1000$ как у человека из Тулы.
На мой взгляд это довольно справедливо.
Такая мотивация предлагает: работай лучше, делай больше и получишь доход больше. А не "вали из NY в деревню и там сможешь сидя на заднице, ничего не делая получать тысячи баксов"
А можно поинтересоваться в какой компании вы работаете?
PS Чтобы удобнее было ковыряться в терминале стоит установить Hacker's keyboard, там есть все обычные кнопки от настольной физической клавиатуры
Сам по себе AnLinux ничего не делает, это просто ланчер, который говорит Termux какие пакеты поставить. Termux неплохо много чего умеет, но он использует какие-то свои репозитарии и чуть более сложные программы в нём не работают или работают плохо, также там есть отсавание по версиям.
Есть замечательный проект, который решает все эти проблемы: https://userland.tech/
Он позволяет запустить в Proot контейнере несколько полноценных версий линукса: Ubuntu, Debian, Alpine. Конечно ограчения контейнера всё равно где-то заметны, но количество софта, которое нормально работает гораздо больше, чем под Termux. Например я могу выкачать свой репозитарий с Angular 10 фронтом и .net core 3.1 backend, собрать всё и запустить прямо на телефоне. Причём работает всё вполне с разумной скоростью, долго только пакеты выкачиваются первый раз. Также успешно запускается MariaDB, Mongo вроде пробовал, но не помню результат. Есть доступ по SSH из сети, то есть вы можете сделать свой реальный сервер на телефоне, только придётся поковыряться в настройках экономии энергии, чтобы телефон не убивал контейнер.
Вопрос "зачем?" задавать не вижу смысла, любому гику понравится идея запустить полноценный веб хостинг прямо на телефоне — это же весело :)
В SQL базах тоже проблем хватает. Вот мы настроили версионирование через миграции, даже вроде внимательно пишем Down миграции и вот налили что-то в прод и поняли, что не то и надо откатить… В 90% случаев такая история заканчивается восстановлением из бекапа и кучей ночной работы :(
Я в 2012-2013 плотно работал с монгой в качестве быстрого кэша перед MS SQL, на тот момент в среднем раз в неделю один из 12 шардов умирал без явных причин. Т.к. это был кэш, не было проблемы его переинициализировать, но как единственную базу данных я бы монгу не стал использовать.
У вас бывали подобные проблемы? Как решили?
Вот, именно это я выше описал. Это ад, при хоть сколько-нибудь большом проекте.
Потому что вся работа с базой завязана на одно узкое место: команду dba.
Ладно бы, если вас было несколько десятков, но dba в всегда один и он ничего не успевает.
А ещё высшие степени вроде "вся, каждый" и так далее намекает на далекость от реального мира промышленной разработки :)) всё то каждый не окупается, всегда должен быть баланс между затратами и выхлопом, чтобы бизнес деньги заработал
А если у меня все данные не помещаются на один сервер?
Или если процессорных мощностей одного сервера не хватает?
А если у меня приложение должно работать в 30 региональных экземплярах расположенных по всему миру?
Оказывается, что база данных никаким образом не может хранить и энфорсить всю бизнес логику моего приложения. Значит, мне придется либо часть логики класть в базу, а часть оставлять в "фронтенде", либо уже сдаться и использовать базу просто как коробочку для строк. К тому же таких коробочек у меня десятки в каждом экземпляре приложения. А всю логику поддержания целостности данных реализовать снаружи. Более того, по мере развития моего приложения, я могу менять выбор базы данных, мигрировать на другие движки, которые например дешевле. Ведь платить за работу 200 баз данных довольно дорого и если я сэкономлю 20% миграцией на другой движок, руководство это вполне одобрит.
Но это конечно специфический пример, просто, чтобы показать, что не всегда можно всю бизнес логику положить в базу. Мы же тут собрались как писатели глобальных стартапов на миллиарды пользователей? :))
А не надо их там хранить. Вы же не храните все свои логи в виде сырых текстовых файлов?
Так и тут, пишите в табличку с датой в названии, а сборщик логов считает, отправит в хранилище, а табличку удалит
По поводу кривых запросов из orm, в целом согласен, кроме самых простых вещей, генератор запросов в тех орм, что приходилось использовать никуда не годится. Очень легко получить N+1, даже в простом случае. На любых более менее крупных проектах, мы используем только материализатор, а запросы пишем сами. Конкретно на шарпе используем Dapper — мне лично больше не нужно
Вы описываете мир, где интеграция нескольких приложений/проектов идёт через базу данных.
Я в таком мире жил некоторое время, очень неприятное место.
Все таблицы скрыты от простых юзеров, доступ на чтение через view, на запись через хранимки. Иначе ведь нельзя ничего менять в структуре, а то разные приложения будут ломаться. С разным релиз циклом.
Любые изменения — это большое трудное ревью.
И всё это в pl/sql, который реально хорошо знает 3 человека, а java знают тысячи.
На мой взгляд более эффективно закрывать базы данных с помощью rest api. Потому что в ресте хорошо проработана версионность и можно поддерживать разные версии апи, так что клиенты не будут знать о том, что внутри что-то поменялось, может мы вообще ушли с сиквела на Mongo. Апи остался тем же. Также код самого апи довольно прямолинейный и может быть написан на популярном языке с развитыми тулами, вроде той же java, c#, typescript.
При этом никто не запрещает делать тонкие оптимизации, там где они нужны. Профилируйте, ищите узкие места, переносите код в хранимки. Но пожалуйста, не делайте интеграцию через базу данных!
Я проводил подобное исследование для своего проекта, в итоге мы перешли с newtonsoft на system text.json, а остальное не стали использовать.
Дело в том, что очень значительный выигрыш производительности получается от строгости парсера. Что utf8json, что system text по умолчанию парсят только полностью валидный json да ещё case sensitive. Это конечно быстрее, но в глобальном апи сервисе, где люди часто для тестирования отправляют запросы руками через postman, а потом эти же строки вставляют в свой код, уже нельзя подходить с такой строгостью. Мы поняли, что мы сломаем колоссальное количество клиентов, если включим case sensitive и полную валидацию (например двойные кавычки, а не одинарные) и тп. Newtonsoft всё пропускает и куча клиентов, к сожалению этим уже пользуются. Так что мы перешли на system text, с настройками максимально близкими к newtonsoft и пока живём так. Надо ещё учитывать, что хотя utf8json правда парсит в 4 раза быстрее, общая цена парсинга в нашем запросе около 5%, то есть мы не можем так уж много выиграть даже от 100% оптимизации
А ещё вот это весь flux/redux…
На мой взгляд flux пытается таким заковыристым способом решить проблему отсутствия типизации. Если создавать модели со строгой типизацией, то смысл flux ускользает
Писать бекенд на nodejs с JavaScript вместо Шарпа, добровольно?
Похоже совсем сильно выгорели :)))
Я много писал на классическом .net, в том числе несколько лет на wpf — это было тёмное время ')
А потом перешёл на .net core web api + angular 2 и старше, также много бекенда на java + spring делал. В итоге мне доставляет большое удовольствие писать бекенд на net core, а фронт на ангуляр 10.
Терпеть не могу чистый JavaScript и стараюсь никак его не касаться
Количество, которое вы называете никак не нагрузит базу данных. Список на миллион доменных имён или транзакций занимает пару десятков мегабайт памяти и легко помещается в кэш, с ним limit и offset прекрасно сработают. В статье упоминается Фейсбук и другие гиганты и я бы предполагал размер таблиц изменяющийся хотя бы десятками гигабайт. Такую таблицу реально не имеет никакого смысла отображать в гуе с полной пагинацией. Это как если бы Гугл позволял посмотреть результаты поиска вплоть до 100млн.
Так что я поддерживаю NoRegrets, на таких больших данных работают фильтры + limit без пагинации. Но бывает реально трудно это объяснить пользователям, которые по старинке хотят "а можно всё посмотреть?"
Почему же редко используете? На мой взгляд как раз логично во всех запросах всегда задавать top или limit, равный максимальному разумному числу строк, которые мы ожидаем получить. Чтобы не случилось, что из-за бага в коде фильтрации, мы случайно попросил у базы 100500000 записей, перегрузили и базу и бекенд при этом
Если только в этом загвоздка, они спокойно могут наладить выпуск сертификатов для известных открытых проектов бесплатно
Десктопный Линукс это миф :) его никогда и не было и не будет. Потому что Линукс пишут фанаты консоли и unix way им самим не нужен удобный визуальный интерфейс как для простых смертных