В третьем случае я статью пролистал до взлета, рука дрожала над минусом, но в итоге не влепил. Мне а) не было времени разбираться, сгенерированная статья или нет б) статья действительно слабая, но стоит ли минуса? В рамках баланса, задним числом, не хотелось бы видеть у таких "произведений" выше 25.
Я мысль у Luke Smith (канал на YT) такую подчерпнул: чем доступнее становится ПО, не тем меньше становится запросов от "заблудившихся" пользователей, а тем далее падает уровень привлеченных пользователей, в итоге условных "дураков"-юзверей стало больше.
То есть как бы и хочется упростить жизнь, но потом все равно придется сражаться с ламерами, которым всё разжуй. И может быть выход тогда только в принудительной монетизации поддержки?
От себя же, прочувствовав боль из статьи за длинным опытом, пытаюсь именно так и писать тексты, чтобы не только показывать шаги, но и объяснять для чего каждый нужен. Какое это иначе обучение? ...хотя припоминаю, оставались такие, которым влом/слишком длинно/"ничего не понял"/"у меня картинки не совпадают" при наличии четких оговорок, куда идем и где что искать.
Пожалуйста, нейрогенераторы на ура справляются с fuzzy запросами. И после этого можно надеяться, что с трудом разобравшийся пользователь напишет толковое пошаговое пособие?
Я уже не знаю, когда последний раз покупал плоды "бездушевной" разработки, условное ААА с пребольшими командами и работой исключительно по таскам, без понимания игры. Тем приятнее читать тут, что каждому новому члену команды они презентации по вселенной делали.
Я вообще не в теме, но пальцем в небо: порог вхождения ниже всего. А не как у упомянутой 3D-модели: концепт+художник, моделист, аниматор. Получается, что ближе всего к рисованию, т.е. для многих простое (в исполнении) продолжение хобби.
Эту Auracast еще принимающее устройство должно без выпендрежа поддерживать. У меня есть пара наушников, которые, видимо, только через своё приложение к вещанию цепляться могут.
На настольных компьютерах управляете настройками ВЫ. А тут функционал "проигрывает ли еще кто-то аудио" встроен в систему и управляется приложениями. Если приложение не дает настройки такое поведение отключить, то ничего вы поделать не сможете. А если нет рута (или вендорских надстроек), то и с этим API ничего нельзя поделать.
Android в нынешнем виде - сугубо потребительское устройство.
Глубокоуважаемый, безмерно дорогой и светлый автор статьи, не только во всей заключительной главе видно, что вы собираетесь зайти на второй круг хождения по граблям, но и по предыдущим вставкам тоже. И если вы с набитыми шишками уйдете с нынешними выводами, то второй круг обеспечен, а я не хочу его допускать. Сразу достигнуть дзена и прыгнуть к финалу можно (и помочь в этом может прочтение git-scm и подглядывание за очень крупными проектами, там же есть глава про разные методы организации работы).
Я не спрашивал ни одного из авторов таких статей, как они это сделали. И, возможно, зря
Мне кажется, они уже из группы тех авторов, которые статьи строчат как на конвеере. Значит, параллельно с кодом метят писать статью. Тогда и заготовки в виде тегов, а может даже скриншотов и отрывков мыслей будут под рукой для написания статьи.
Я вел GitHub репозиторий и аккуратно протоколировал все действия. Правило было буквально одно — ответственно относиться к коммитам.
Может, коммиты и атомарны, но названия у них не говорящие. И тут, может, уместно будет описать точки зрения, для которых важны описания коммитов:
разработчик: не запутаться самому в том, что сделал
ответственный за репозиторий: понять куда, что, и зачем? А еще именно здесь нужна атомарность и хорошее наименование, чтобы в случае проблем можно было откатить проблемный коммит и только его одного. В целях портирования коммитов и целостности истории, любые переписывания истории не допустимы при типичной работе. Для этого есть git revert, который 🥁...создает еще один коммит без дерганья истории.
автор ретроспективы: перекликается с пунктом 2, но хочется еще тупиковую историю изменений иметь. Обычно она оседает в проекте либо в виде непрошедших дискуссий/Pull Request-ов, либо в локальной репе, но тогда никуда не публикуется
1,2,3 // PM: runtime: Documentation: ABI: Document time units for *_time
4, 5 // Many .../power/... time-related attributes have an "_ms" suffix and also include language in their ABI description to make clear that their time is measured in milliseconds. However, 'runtime_suspended_time' and 'runtime_active_time' have neither, and it takes me a nontrivial amount of time to poke through the source to confirm that they are also measured in milliseconds. Update the doc with "millisecond" units.
Куда: PM, power management subsystem
Что: документация
Чего: единиц измерения
Что именно
И почему
Поскольку ядро разрабатывается через эл. почту, то коммиты должны содержать не только сам код, но и полное пояснение всего, т.е. даже аргументацию нужности и важности. Поэтому и видна эта структура из четкого оглавления и подробного описания, где нет необходимости лезть и смотреть на измененные участки кода, чтобы прыгнуть в истории/откатить что-то. Атомарность коммитов заключается в том, что каждый можно откатить по отдельности при сохранении рабочей системы.
Переписывать историю нельзя, потому что это ломает весь workflow, а гит на него завязан: а) проверка истории с точки зрения безопасности б) не делать лишние телодвижения.
И после прочтения статьи, я так и не понял зачем переписывать историю здесь. Где нельзя уложиться в "надо подстроиться под инструмент, чтобы им продуктивно пользоваться"?
Ветка основная: ход повествования и развитие кода
Ответвление: тупиковый эксперимент, над которым некоторое время велась/будет вестись работа
Слияние с основной веткой: хороший эксперимент, перенимаем
Тег: на чем заострить внимание при написании статьи. Это не отдельная рабочая ветка, а один момент времени. Причем у тегов тоже может быть полновесное описание.
В этом пункте я не согласен с идей из статьи: "но вы хотите сохранить его в истории или, например, вы наткнулись на показательный баг, создайте ветку." - так как не предусмотрена дальнейшая разработка (пока), то не нужно делать ветку. Иначе же, если начинаете эксперементировать ("тупиковый сценарий" или нет), то сразу это делайте через отдельные ветки. Внедрение хороших экспериментов сразу видно через merge той ветки.
Если вам захотелось переписывать историю, то неизбежно придется обновлять всё, что ниже по хронологическому течению. Еще и поэтому этого делать не надо, но git rerere может упростить жизнь и запомнить принятые вручную решения при редактировании конфликтов.
А вам захочется ее переписать. Причин может быть множество:
На первое сразу отвечаю НЕТ, а на второе:
Спустя 10 коммитов вы поняли, как можно написать показательнее и прозрачнее
Значит спустя этих десять коммитов и будет, наконец, переименование.
Вы осознали, насколько дурацкое имя у функции, которую вы написали еще в самом начале работы с кодом, и вся история и все коммиты пронизаны использованием этой функции
Аналогично. Бывает. C'est la vie.
Вы хотите немного поменять местами хронологию событий
И это удобно делать, когда у вас маленькая ветка, которую вы готовите в виде PR. А не когда вы увлеклись переписыванием истории, и потому приходится обновлять еще N других веток, чтобы их синхронизировать. А если для написания статьи, то гит теребить незачем. Статья в этом смысле write-only: понадергали кода из гита, "обновили" его в статье, чтобы читался и был понятен в виде повествования и всё.
Вывод один, и он скучен: под инструмент надо подстраиваться. Но не критично, а созданные проблемы -- ССЗБ.
Это фича Android-а, а вы, пользователь, хавайте, что дают. У Samsung через какое-то (Good Lock?) приложение можно, насколько понял, отключить эту фичу.
git, вероятно, не лучший инструмент, не лучшая система контроля версий для подобной задачи, где постоянное переписывание истории коммитов — типовой рабочий процесс.
Другими словами, автор всё ещё не понял негласные правила пользования гитом. Нет, гласные, но их вычитывать надо. И перемена истории, которая затрагивает еще пачку предыдущих веток, к "нормальному" поведению точно не относится.
Суть git-а как блокчейна -- в его линейности. Не нравится изначальное название функции? Если вы всё ещё в своей локальной ветке - перетасовывайте и переименовывайте как душе угодно. Опубликованные коммиты? Не трогать! Переименуй сейчас атомарным коммитом и портируй на старые ветки, коль угодно. Про дневник выше -- хорошая метафора.
Я не забываю, но я понял почему я так пишу, в абсолютистском ключе. Так я пытаюсь донести мысль наихудшего сценария развития, чтобы другие не забывали в каком мире живут и к чему могут привести сегодняшние устои (и для меня картина кажется близкой к истине).
Правда, если брать пропаганду как самоцель, то строчение комментариев -- не самое выгодное вложение времени, когда можно умножить аудиторию имея свой канал/блог, писать статьи (да хоть тут же).
Что касается торрентов, когда небезызвестная (ый) EMPRESS довыделывалась, ей очевидно одна из контор/правоохранительные органы наступили на хвост, и вроде как опять никого не стало, кто бы ломал Denuvo. Я пусть последние релизы не покупаю и не играю, но именно с точки зрения сохранения культуры это дело важное. А хомяки консольные -- для меня равно клинический случай в этом плане. Платить деньги за то, что бы тебя, как потребителя, в долгую поимели.
All jabber.ru and xmpp.ru communications between these dates should be assumed compromised. Given the nature of the interception, the attacker have been able to execute any action as if it is executed from the authorized account, without knowing the account password. This means that the attacker could download account's roster, lifetime unencrypted server-side message history, send new messages or alter them in real time.
End-to-end encrypted communications, such as OMEMO, OTR or PGP, are protected from the interception only if both parties have validated the encryption keys. The users are asked to check their accounts for new unauthorized OMEMO and PGP keys in their PEP storage, and change passwords.
В третьем случае я статью пролистал до взлета, рука дрожала над минусом, но в итоге не влепил. Мне а) не было времени разбираться, сгенерированная статья или нет б) статья действительно слабая, но стоит ли минуса? В рамках баланса, задним числом, не хотелось бы видеть у таких "произведений" выше 25.
Аналогичная ситуация с плохими и посредственными переводами. Люд уже свой язык позабыл (привык), чтобы претензии выкатывать.
Я мысль у Luke Smith (канал на YT) такую подчерпнул: чем доступнее становится ПО, не тем меньше становится запросов от "заблудившихся" пользователей, а тем далее падает уровень привлеченных пользователей, в итоге условных "дураков"-юзверей стало больше.
То есть как бы и хочется упростить жизнь, но потом все равно придется сражаться с ламерами, которым всё разжуй. И может быть выход тогда только в принудительной монетизации поддержки?
От себя же, прочувствовав боль из статьи за длинным опытом, пытаюсь именно так и писать тексты, чтобы не только показывать шаги, но и объяснять для чего каждый нужен. Какое это иначе обучение? ...хотя припоминаю, оставались такие, которым влом/слишком длинно/"ничего не понял"/"у меня картинки не совпадают" при наличии четких оговорок, куда идем и где что искать.
Пожалуйста, нейрогенераторы на ура справляются с fuzzy запросами. И после этого можно надеяться, что с трудом разобравшийся пользователь напишет толковое пошаговое пособие?
Не, очень даже нейтрально от себя высказываюсь.
Я уже не знаю, когда последний раз покупал плоды "бездушевной" разработки, условное ААА с пребольшими командами и работой исключительно по таскам, без понимания игры. Тем приятнее читать тут, что каждому новому члену команды они презентации по вселенной делали.
Я вообще не в теме, но пальцем в небо: порог вхождения ниже всего. А не как у упомянутой 3D-модели: концепт+художник, моделист, аниматор. Получается, что ближе всего к рисованию, т.е. для многих простое (в исполнении) продолжение хобби.
Вы точно друг друга услышали?
Позволю заметить, что трендозадающей игрой стал Minecraft с геймплейной идеей на миллиард: дать игрокам, наконец-то, песочницу.
Спасибо.
Эту Auracast еще принимающее устройство должно без выпендрежа поддерживать. У меня есть пара наушников, которые, видимо, только через своё приложение к вещанию цепляться могут.
На настольных компьютерах управляете настройками ВЫ. А тут функционал "проигрывает ли еще кто-то аудио" встроен в систему и управляется приложениями. Если приложение не дает настройки такое поведение отключить, то ничего вы поделать не сможете. А если нет рута (или вендорских надстроек), то и с этим API ничего нельзя поделать.
Android в нынешнем виде - сугубо потребительское устройство.
Глубокоуважаемый, безмерно дорогой и светлый автор статьи, не только во всей заключительной главе видно, что вы собираетесь зайти на второй круг хождения по граблям, но и по предыдущим вставкам тоже. И если вы с набитыми шишками уйдете с нынешними выводами, то второй круг обеспечен, а я не хочу его допускать. Сразу достигнуть дзена и прыгнуть к финалу можно (и помочь в этом может прочтение git-scm и подглядывание за очень крупными проектами, там же есть глава про разные методы организации работы).
Мне кажется, они уже из группы тех авторов, которые статьи строчат как на конвеере. Значит, параллельно с кодом метят писать статью. Тогда и заготовки в виде тегов, а может даже скриншотов и отрывков мыслей будут под рукой для написания статьи.
Может, коммиты и атомарны, но названия у них не говорящие. И тут, может, уместно будет описать точки зрения, для которых важны описания коммитов:
разработчик: не запутаться самому в том, что сделал
ответственный за репозиторий: понять куда, что, и зачем? А еще именно здесь нужна атомарность и хорошее наименование, чтобы в случае проблем можно было откатить проблемный коммит и только его одного. В целях портирования коммитов и целостности истории, любые переписывания истории не допустимы при типичной работе. Для этого есть git revert, который 🥁...создает еще один коммит без дерганья истории.
автор ретроспективы: перекликается с пунктом 2, но хочется еще тупиковую историю изменений иметь. Обычно она оседает в проекте либо в виде непрошедших дискуссий/Pull Request-ов, либо в локальной репе, но тогда никуда не публикуется
Гипертрофированный пример у основоположницы надо смотреть, ядро Linux: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=cb12b12ed32626ee2fa6291ba9a90b20a958c5f5
Куда: PM, power management subsystem
Что: документация
Чего: единиц измерения
Что именно
И почему
Поскольку ядро разрабатывается через эл. почту, то коммиты должны содержать не только сам код, но и полное пояснение всего, т.е. даже аргументацию нужности и важности. Поэтому и видна эта структура из четкого оглавления и подробного описания, где нет необходимости лезть и смотреть на измененные участки кода, чтобы прыгнуть в истории/откатить что-то. Атомарность коммитов заключается в том, что каждый можно откатить по отдельности при сохранении рабочей системы.
Переписывать историю нельзя, потому что это ломает весь workflow, а гит на него завязан: а) проверка истории с точки зрения безопасности б) не делать лишние телодвижения.
И после прочтения статьи, я так и не понял зачем переписывать историю здесь. Где нельзя уложиться в "надо подстроиться под инструмент, чтобы им продуктивно пользоваться"?
Ветка основная: ход повествования и развитие кода
Ответвление: тупиковый эксперимент, над которым некоторое время велась/будет вестись работа
Слияние с основной веткой: хороший эксперимент, перенимаем
Тег: на чем заострить внимание при написании статьи. Это не отдельная рабочая ветка, а один момент времени. Причем у тегов тоже может быть полновесное описание.
В этом пункте я не согласен с идей из статьи: "но вы хотите сохранить его в истории или, например, вы наткнулись на показательный баг, создайте ветку." - так как не предусмотрена дальнейшая разработка (пока), то не нужно делать ветку. Иначе же, если начинаете эксперементировать ("тупиковый сценарий" или нет), то сразу это делайте через отдельные ветки. Внедрение хороших экспериментов сразу видно через merge той ветки.
Если вам захотелось переписывать историю, то неизбежно придется обновлять всё, что ниже по хронологическому течению. Еще и поэтому этого делать не надо, но git rerere может упростить жизнь и запомнить принятые вручную решения при редактировании конфликтов.
На первое сразу отвечаю НЕТ, а на второе:
Значит спустя этих десять коммитов и будет, наконец, переименование.
Аналогично. Бывает. C'est la vie.
И это удобно делать, когда у вас маленькая ветка, которую вы готовите в виде PR. А не когда вы увлеклись переписыванием истории, и потому приходится обновлять еще N других веток, чтобы их синхронизировать. А если для написания статьи, то гит теребить незачем. Статья в этом смысле write-only: понадергали кода из гита, "обновили" его в статье, чтобы читался и был понятен в виде повествования и всё.
Вывод один, и он скучен: под инструмент надо подстраиваться. Но не критично, а созданные проблемы -- ССЗБ.
Это фича Android-а, а вы, пользователь, хавайте, что дают. У Samsung через какое-то (Good Lock?) приложение можно, насколько понял, отключить эту фичу.
Не путайте BLE и Bluetooth. BLE Audio реализовано поверх этого нового типа передачи данных, в том числе Auracast.
Другими словами, автор всё ещё не понял негласные правила пользования гитом. Нет, гласные, но их вычитывать надо. И перемена истории, которая затрагивает еще пачку предыдущих веток, к "нормальному" поведению точно не относится.
Суть git-а как блокчейна -- в его линейности. Не нравится изначальное название функции? Если вы всё ещё в своей локальной ветке - перетасовывайте и переименовывайте как душе угодно. Опубликованные коммиты? Не трогать! Переименуй сейчас атомарным коммитом и портируй на старые ветки, коль угодно. Про дневник выше -- хорошая метафора.
Свобода воли она такая - головной свист почти не извести.
Доигрались в shareholder value.
С учетом инфляции это прям ровно 50 млрд. https://data.bls.gov/cgi-bin/cpicalc.pl?cost1=31.8&year1=200707&year2=202508
Я не забываю, но я понял почему я так пишу, в абсолютистском ключе. Так я пытаюсь донести мысль наихудшего сценария развития, чтобы другие не забывали в каком мире живут и к чему могут привести сегодняшние устои (и для меня картина кажется близкой к истине).
Правда, если брать пропаганду как самоцель, то строчение комментариев -- не самое выгодное вложение времени, когда можно умножить аудиторию имея свой канал/блог, писать статьи (да хоть тут же).
Что касается торрентов, когда небезызвестная (ый) EMPRESS довыделывалась, ей очевидно одна из контор/правоохранительные органы наступили на хвост, и вроде как опять никого не стало, кто бы ломал Denuvo. Я пусть последние релизы не покупаю и не играю, но именно с точки зрения сохранения культуры это дело важное. А хомяки консольные -- для меня равно клинический случай в этом плане. Платить деньги за то, что бы тебя, как потребителя, в долгую поимели.
Это хорошо. А диски прежние через внешний дисковод использовать можно?
Или @Milfgard, он давно про свою книгу писал, как спорил с издательством, чтобы за книгой не охотились в местах обитания пиратов.
Много "если": Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service