Ну это же вопрос "как выбрать библиотеку для Х, если этого нет в стандартной библиотеке".
Вот я плохо знаю инфраструктуру Python (использую, конечно, его как клей или мелкие сервисы на работе).
Завтра захочу найти библиотеку, ну не знаю для парсинга plain-text (вроде в стандартной библиотеке такого нет). Как мне найти правильную библиотеку на Python для этого?
Я не начинаю писать на Python что-либо если моя оценка "больше 1000 строк кода".
1 KLoC оценки обычно превращаются в 2 KLoC написанного кода, включая нюансы. Если сервис выходит за 5 KLoC - то после этого объёма прототип перестаёт быть нормально поддериваемым и каждое возвращение это боль и вспоминание "как вот это сделано".
Теоретически - наверное на Python можно инженерить ПО. Но зачем тогда вообще Python если его киллер-фичу (возможность бысто запрототипировать) мы вообще не используем.
То, что в раст свежая, прям "нулёвая" экосистема - это приятно. Вместо Make / CMake / Doxygen / ... просто cargo xxx. Но это может и протухнуть лет за 10.
Но давайте дадим слово начальнику транспортного цеха? Как всё-таки Rust меняет мышление?
Вот мне с Haskell понравилось (реально появилось много хороших приёмов в программировании). А с Rust - мне кажется у меня ситуация обратная ожиданиям.
Ожидание - написание программ на Rust это доведение до автоматизма практик написания кода, где некоторые классы ошибок в принципе отсутствуют. Реальность - Rust настолько хоршо тебя контролирует, что ты даже забываешь думать о таких ошибках. И при переходе с Rust на привычные языки (скажем на C где у нас низкоуровневые библиотеки) - пару дней приходится заново привыкать следить за вещами, которые за тебя делал Rust.
Если "упрощающая пояснялка" - и есть текст договора, то идея хорошая.
Если же вы подписываете юридический документ, а к нему прилагается не имеющая силы "упрощающая пояснялка" - то идея плохая.
Попробую пояснить почему: Если всё идёт хорошо - то "вот деньги вот работа" - тут договор вообще не нужен. Договор нужен только в тот момент, когда что-то пошло не так. А как только что-то пошло не так - тут же люди начинают зарываться в пункты мелким шрифтом со звёздочками и спорить что это значит.
То есть "если всё хорошо" - упрощающая пояснялка просто не нужна вообще. Если "что-то пошло плохо" - упрощающая пояснялка не актуальна, надо читать полный текст. В итоге ни в одном из сценариев использования "упрощающая пояснялка" не нужна.
Смысл фреймворка в том числе и в том, чтобы разрабатывать используя код.
Мне совершенно не понятно что это значит.
Фреймворк предлагает некоторый "способ разработки". В теории - "хороший" подходящий вам и достаточно безопасный. На практике - выясняется что таке фреймворки часто сырые (что уменьшает его преимущества). Его недостатки, в этом случае всё равно остаются.
Ну есть какая-то "методика нормализации" просмотров в "долю от прибыли корпорации".
Ну пусть будет 2%. Т.е. 2% прибыли - это доходы "всех продюссеров". Делются пропорционально между всеми продюссерами. Но деньги за первые 60 дней проката из этих 2% вычитаются чтобы "окупить затраты". Т.е. все продюссеры всего получают: 2% * X, где X < 1 и зависит от того как много просмотров пришлось на первые 60 дней.
Вот для КТВ это Х было небольшим (ну пусть будет 1.5% прибыли таки шло продюссерам).
А на стрименге оказалось, что бОльшая часть всех просмотров - в первые 60 дней. В итоге это Х - меньше 50% (ну пусть будет 0.5% всех просмотров после первых 60 дней).
Проблема в том, что не существует машины U+ (способной вычислить не не останавливающуюся программу и возвращающей not-ended) и U++ (способной вычислить бесконечное количество U+)
Однако я бы хотел отметить, что современные смартфоны используют методы вычислительной фотографии, где несколько кадров могут быть наложены друг на друга - в таком случае дополнительная точность не будет лишней, ведь итоговый динамический диапазон после склейки вполне может вырасти выше 10 стопов.
Так мы по нескольким кадрам не только шум можем убрать, но и дополнительную информацию вытащить (грубо говоря как среднее арифметическое значений (квадратов значений?)). Грубо говоря те несколько кадров что у нас есть - это и есть "больше информации".
30 евро\месяц. Но это примерно 1 час с репетитором или 2 часа занятий с групповых (ну или если хотите 1 женская стрижка или 2 мужских).
Т.е. вы вот взяли самый большой пласт расходов на технику (мой ПК хоть и дороже - покупался лет 10 назад) и он совершенно незначителен, в сравнении с услугами.
Скажите, а курсы на которых вы препоадёте можно оплачивать "помесячно"? Или только единым платежём? Вы видите в этом проблему?
Выпускники курсов имеют неверное представление о профессии в целом. Вот хотим нанять junior QA (тестера с целью сделать его QA). Все выпускники курсов "знают" postman / jira / sql-запросы (плюс куча технологий написана в кототрых они вообще не разбираются). Понимания что под капотом нет совсем. Почти поверил что это норма, - но в четверг беседовал с парнем-самоучкой. Результат - решили выпускников курсов не рассматривать вообще.
Не знаю как так получается, но выпускиники курсов постоянно врут. Они почти на любой вопрос отвечают "знаю", после проверочных вопросов выясняется что уровень знаний: "на курсах упоминали такую аббривиатуру".
Ну по-существу автор считает, что он наработал на ачивку "контрибьютор", а мэйнтейнер считает, что не наработал. По причине, что 0 строк автора осталось в исходном коде.
Если смотреть формально - то не наработал. Если смотреть фактически - то большинсво работы выполнил автор. Вывод - наверное надо иметь какую-то промежуточную ачивку между reported - contributor.
да не копируем итератор итератор в отдельную переменную на каждой итерации (и замыкаемся по ссылке на копию). Если копией не воспользовались - всё отлично DCE её легко удалит.
Копируете переменную цикла. Замыкаетесь по копии переменной. Удаляете ненужные скопированные переменные (на стеке DCE справится, а вот если сделали выделение памяти - надо уже ручками удалять).
Тогда моё update наверное не верно. Если у примитивных типов нет технического деструктора (вызываемого language-runtime, в абсолютном большинстве случаев не вызываемого), не на что навесить нужную логику (вводить его сейчас, понятно, поздновато).
И значит скорее всего надо отдельно делать циклы без замыканий (ничего не менять) \ отдельно циклы где замыкания захватывают переменную цикла.
А как сейчас в Го продляется жизнь замкнутых переменных со стека? Через двойной указатель и копирование в кучу при выходе из скоупа?
Ну и теоретически можно предусмотреть отдельную машинерию только если замыкание захватывает переменную цикла.
Upd: если в го есть понятие "объект расположенный на стеке" (с конструкторами \ деструкторами которые компилятор умеет элиминировать если они пустые) - то даже специальный случай вроде не потребуется.
Ну это же вопрос "как выбрать библиотеку для Х, если этого нет в стандартной библиотеке".
Вот я плохо знаю инфраструктуру Python (использую, конечно, его как клей или мелкие сервисы на работе).
Завтра захочу найти библиотеку, ну не знаю для парсинга plain-text (вроде в стандартной библиотеке такого нет). Как мне найти правильную библиотеку на Python для этого?
э... это какая-то очень тонкая, понятная лишь избранным ирония?
Если так - поясните для более приземлённых пользователей Хабра.
Я не начинаю писать на Python что-либо если моя оценка "больше 1000 строк кода".
1 KLoC оценки обычно превращаются в 2 KLoC написанного кода, включая нюансы.
Если сервис выходит за 5 KLoC - то после этого объёма прототип перестаёт быть нормально поддериваемым и каждое возвращение это боль и вспоминание "как вот это сделано".
Теоретически - наверное на Python можно инженерить ПО. Но зачем тогда вообще Python если его киллер-фичу (возможность бысто запрототипировать) мы вообще не используем.
Вы про Rust или про статью?
Если про Rust - то, да будет кардинально проще (если придираться контрольного "изучить Rust не зная Haskell и C++").
Хотя от понимания машинерии многих мелких нюансов это вас это не убережёт.
То, что в раст свежая, прям "нулёвая" экосистема - это приятно. Вместо Make / CMake / Doxygen / ... просто cargo xxx. Но это может и протухнуть лет за 10.
Но давайте дадим слово начальнику транспортного цеха? Как всё-таки Rust меняет мышление?
Вот мне с Haskell понравилось (реально появилось много хороших приёмов в программировании).
А с Rust - мне кажется у меня ситуация обратная ожиданиям.
Ожидание - написание программ на Rust это доведение до автоматизма практик написания кода, где некоторые классы ошибок в принципе отсутствуют.
Реальность - Rust настолько хоршо тебя контролирует, что ты даже забываешь думать о таких ошибках. И при переходе с Rust на привычные языки (скажем на C где у нас низкоуровневые библиотеки) - пару дней приходится заново привыкать следить за вещами, которые за тебя делал Rust.
Если "упрощающая пояснялка" - и есть текст договора, то идея хорошая.
Если же вы подписываете юридический документ, а к нему прилагается не имеющая силы "упрощающая пояснялка" - то идея плохая.
Попробую пояснить почему:
Если всё идёт хорошо - то "вот деньги вот работа" - тут договор вообще не нужен.
Договор нужен только в тот момент, когда что-то пошло не так. А как только что-то пошло не так - тут же люди начинают зарываться в пункты мелким шрифтом со звёздочками и спорить что это значит.
То есть "если всё хорошо" - упрощающая пояснялка просто не нужна вообще.
Если "что-то пошло плохо" - упрощающая пояснялка не актуальна, надо читать полный текст.
В итоге ни в одном из сценариев использования "упрощающая пояснялка" не нужна.
Мне совершенно не понятно что это значит.
Фреймворк предлагает некоторый "способ разработки".
В теории - "хороший" подходящий вам и достаточно безопасный.
На практике - выясняется что таке фреймворки часто сырые (что уменьшает его преимущества). Его недостатки, в этом случае всё равно остаются.
Ну есть какая-то "методика нормализации" просмотров в "долю от прибыли корпорации".
Ну пусть будет 2%.
Т.е. 2% прибыли - это доходы "всех продюссеров". Делются пропорционально между всеми продюссерами. Но деньги за первые 60 дней проката из этих 2% вычитаются чтобы "окупить затраты". Т.е. все продюссеры всего получают: 2% * X, где X < 1 и зависит от того как много просмотров пришлось на первые 60 дней.
Вот для КТВ это Х было небольшим (ну пусть будет 1.5% прибыли таки шло продюссерам).
А на стрименге оказалось, что бОльшая часть всех просмотров - в первые 60 дней.
В итоге это Х - меньше 50% (ну пусть будет 0.5% всех просмотров после первых 60 дней).
Ну так программу написать не проблема.
Проблема в том, что не существует машины U+ (способной вычислить не не останавливающуюся программу и возвращающей not-ended) и U++ (способной вычислить бесконечное количество U+)
физически живут в часе езды от даунтауна (а не в соседнем штате).
Так мы по нескольким кадрам не только шум можем убрать, но и дополнительную информацию вытащить (грубо говоря как среднее арифметическое значений (квадратов значений?)).
Грубо говоря те несколько кадров что у нас есть - это и есть "больше информации".
30 евро\месяц.
Но это примерно 1 час с репетитором или 2 часа занятий с групповых (ну или если хотите 1 женская стрижка или 2 мужских).
Т.е. вы вот взяли самый большой пласт расходов на технику (мой ПК хоть и дороже - покупался лет 10 назад) и он совершенно незначителен, в сравнении с услугами.
Скажите, а курсы на которых вы препоадёте можно оплачивать "помесячно"? Или только единым платежём?
Вы видите в этом проблему?
Выпускники курсов имеют неверное представление о профессии в целом.
Вот хотим нанять junior QA (тестера с целью сделать его QA). Все выпускники курсов "знают" postman / jira / sql-запросы (плюс куча технологий написана в кототрых они вообще не разбираются). Понимания что под капотом нет совсем. Почти поверил что это норма, - но в четверг беседовал с парнем-самоучкой. Результат - решили выпускников курсов не рассматривать вообще.
Не знаю как так получается, но выпускиники курсов постоянно врут. Они почти на любой вопрос отвечают "знаю", после проверочных вопросов выясняется что уровень знаний: "на курсах упоминали такую аббривиатуру".
Намного чаще чем "что"? Сравнительная степень, где второй параметр для сравнения?
Ну по-существу автор считает, что он наработал на ачивку "контрибьютор", а мэйнтейнер считает, что не наработал. По причине, что 0 строк автора осталось в исходном коде.
Если смотреть формально - то не наработал.
Если смотреть фактически - то большинсво работы выполнил автор.
Вывод - наверное надо иметь какую-то промежуточную ачивку между reported - contributor.
да не копируем итератор итератор в отдельную переменную на каждой итерации (и замыкаемся по ссылке на копию).
Если копией не воспользовались - всё отлично DCE её легко удалит.
Копируете переменную цикла. Замыкаетесь по копии переменной. Удаляете ненужные скопированные переменные (на стеке DCE справится, а вот если сделали выделение памяти - надо уже ручками удалять).
ПС
Желательно эти 3 фазы поставить подряд.
Спасибо.
Тогда моё update наверное не верно. Если у примитивных типов нет технического деструктора (вызываемого language-runtime, в абсолютном большинстве случаев не вызываемого), не на что навесить нужную логику (вводить его сейчас, понятно, поздновато).
И значит скорее всего надо отдельно делать циклы без замыканий (ничего не менять) \ отдельно циклы где замыкания захватывают переменную цикла.
А как сейчас в Го продляется жизнь замкнутых переменных со стека?
Через двойной указатель и копирование в кучу при выходе из скоупа?
Ну и теоретически можно предусмотреть отдельную машинерию только если замыкание захватывает переменную цикла.
Upd: если в го есть понятие "объект расположенный на стеке" (с конструкторами \ деструкторами которые компилятор умеет элиминировать если они пустые) - то даже специальный случай вроде не потребуется.
По noise pollution (noise poison - неверный термин, извините) ищется например:
https://www.hsph.harvard.edu/news/press-releases/exposure-to-high-pollution-levels-during-pregnancy-may-increase-risk-of-having-child-with-autism/