Вот очень не люблю когда используют слово intent для, по сути, моделирования действий для достижения этого самого замысла. Как пример, я как пользователь, открываю офисный пакет с замыслом написать новое резюме на новое место работы о чем офисный пакет и понятия не имеет — он только видит действие (запуск программы).
В этом же и есть вся сложность разработки, что инженер пытается дать пользователю как можно больше возможных действий и упрощать их комбинирование для того, чтобы пользователю было легко реализовать его intent. И при этом инженер никогда и не знает о замысле пользователей — он только гадает и предполагает, и закладывает поддержку действий исходя из своих предположений.
И это очень кривая дорожка, когда инженер начинает предполагать, что совершение действий и есть замысел пользователя — ну вот никогда не будет у пользователя замысла нажать кнопку «Д». Он не будет просыпаться с утра и думать «ах да, надо не забыть нажать кнопку «Д» в программе Х». Все это ведёт к появлению абсолютно бесполезных программ и неработающих концепций.
Извините что немного не по теме статьи написал, затриггерило :)
Тысячи и тысячи вещей влияют на принятие решений в проекте. Вот, например, amarao верно подмечает прозрачность намерения. Но от этого принцип за тем же KISS не меняется, по моему мнению. Эти лучшие практики про то как писать код являются одним небольшим срезом к успешному проекту. В этой статье речь лишь про то, что вроде как можно этот срез формализировать а уже имея формальные критерии маленького среза можно дальше смотреть на влияние все этих лучших практик на проект.
В статье как раз все идёт к простоте. Но я разделяю вашу точку зрения — «намерение»(intent) в моей команде главенствующий принцип ревью. То есть, код должен реализовывать явное и непротиворечивое намерение, и это намерение должно быть читаемо из кода. Однако, мне кажется, что хоть это сродни простоте, но это все же про лёгкость: simple vs easy.
Вы слышали про skip level one to one? Или про OKR? Если слышали, то вот вам и ответ.
Я одно не пойму, как так получается у вас, что можно делегировать ответственность? Ответственность имеет направленность только вверх — ты можешь принять ответственность за нижестоящих, но не можешь делегировать.
То есть, если у менеджера получается делегировать ответственность в вашей компании то значит менеджер менеджера это позволяет. И вопросы на самом деле к менеджеру менеджеров.
—
Ответственность здесь значит accountability, не responsibility. Responsibility как раз нужно делегировать. Не знаю как лучше перевести это два слова, извините.
С чего это вдруг мощность или тип сознания отличаются? Если сознание это про динамику и к-во элементов, то не имеет значение из чего сделан нейрон. Я не вижу как сознание сделанное из меньшего к-ва элементов может оказаться «мощнее». И, кстати, умение ходить после рождения не коррелирует с сознанием.
Гипотеза про то что сознание это свойство сложных динамических структур очень красива и не нова, но для неё не нужны ни люди ни интернет. Если мы берём эту гипотезу за основу, то сознание в каком-то виде должно быть везде.
В ваших измышлениях, правда, отсутсвует ещё один кусок пазла: скорость протекания реакций. С ростом масштаба (читай размер) системы меняется скорость взаимодействия и, соответсвенно, скорость протекания «мысли» у целого.
Так что может интернет и люди как динамическая система и образуют сознание, но учитывая как недавно эта структура образовалась, то сознание целого ещё даже могло не осознать себя — для него прошёл только один микроскопический сознательный миг.
PS. Если что, есть альтернативна гипотезе о сознании как свойство динамических систем. Я сейчас про современный панпсихизм, в котором тоже все очень интересно.
Да, и это реальная проблема для тасовачных машин. Оказалось что сложно сделать машину которая будет делить колоду на две части в недетерминированном месте и тасовать ее неровно (когда каждая карта слева ложиться на каждую справа). То есть повторять «ошибки» людей, которые, в общем, и делают riffle эффективным.
Riffle конечно же, автокоррекция подвела. Оценка количества итераций которую вы привели это почти она. Bayer ее уточнил по тому как люди тасуют карты и оценка чуть-чуть понизилась до тех самых 7.
Эта статья могла бы быть просто великолепна если бы вы использовали математику из этой публикации https://arxiv.org/pdf/math/0501401.pdf. Jonasson в ней доказал что чтобы хорошо перетасовать колоду способом из статьи нужно минимум N^2 log N (для колоды из N карт) повторений, что чуть-чуть далеко от 64.
Кстати, эта же работа ссылается на другую работу в которой был найден самый эффективный способ тасовки — 7 итераций river shuffle.
Кстати да, есть разница в отношении к типу байка. Субъективно, кажется что к адвенчюрам самое нейтрально-уважительное отношение среди байкеров и автомобилистов. Особенно если это какой-нибудь GS обвешанный со всех сторон.
Как вам уже сказали — это миф. Громкий выхлоп на самом деле может стать причиной аварии.
Буквально в этом сезоне наблюдал как на трассе джиксер с примерно +50-70 перепугал водителя в соседней полосе (тот испугался от резкого падения частоты звука и тупо дернул рулем, хорошо в другую сторону). Эффект Доплера превращают аргументы за громкий выхлоп в аргументы против. А на низкой скорости громкий выхлоп только раздражает всех, включая самого байкера.
Вода скользкая. Листва очень скользкая. Рассыпанный гравий — капец. Резиновая прокладка на трамвайных путях — вообще за гранью добра и зла. Мотоцикл очень хорошо заносит, особенно в повороте.
Дополню про плохой контакт с дорогой. Еще опасны середины полос всяким ГСМ, мокрая дорожная разметка, металлические люки, брусчатки, лужи и мокрый асфальт особенно в первые минут 20, пока все ГСМ с дороги водой смывает. И все то же самое сухое, но в холод.
А вообще ATGATT, контрастная одежда, постоянное оттачивание навыков оборонительного вождения, ABS, хорошее знание своего байка и поменьше самоуверенности помогут сильно увеличить шансы доехать.
Насколько я понимаю, у этого движения есть два направления: равные возможности и права, борьба с гендерным стереотипами в обществе влияющие на выбор молодых девушек.
Из лично моего опыта: с равными возможностями и правами все лучше и лучше. Молодые девушки могут выбирать профессию и на собеседованиях к ним относятся нейтральнее или положительно (позитивная дискриминация). Да вы и сами привели в пример OSS.
А вот вторая проблема более сложна. Предполагается что гендерные стереотипы в обществе давят/давили на молодых девушек и поэтому они не выбирают/выбрали программирование. Как с этим бороться, как менять общественное мнение? Кажется что, придумался только один вариант: менять мнение молодых девушек через положительную дискриминацию, таким образом балансируя стереотипы в обществе. Больше девушек на конференциях, больше девушек на рабочих местах, в общем, больше success stories.
Насколько это хорошо я понятия не имею, через лет 10 будет видно.
Удивительно: а почему вы 10 лет продолжаете так жить (предполагаю что зарплата у вас выросла к 80)? Не интересовались своими опциями на глобальном рынке? Если дело в переезде, то на удаленке тимлид с 10 летным опытом наверняка сможет $100к.
https://m.youtube.com/watch?v=6Ij9PiehENA
Можно посмотреть на https://spatial.chat/ как на коммерческую реализацию вашей идеи в продукт.
Больше похоже на Brachycerus muricatus. Тема на реддите https://www.reddit.com/r/whatsthisbug/comments/i70qsa/whats_this_south_african_arthropod_the_picture/
Вот очень не люблю когда используют слово intent для, по сути, моделирования действий для достижения этого самого замысла. Как пример, я как пользователь, открываю офисный пакет с замыслом написать новое резюме на новое место работы о чем офисный пакет и понятия не имеет — он только видит действие (запуск программы).
В этом же и есть вся сложность разработки, что инженер пытается дать пользователю как можно больше возможных действий и упрощать их комбинирование для того, чтобы пользователю было легко реализовать его intent. И при этом инженер никогда и не знает о замысле пользователей — он только гадает и предполагает, и закладывает поддержку действий исходя из своих предположений.
И это очень кривая дорожка, когда инженер начинает предполагать, что совершение действий и есть замысел пользователя — ну вот никогда не будет у пользователя замысла нажать кнопку «Д». Он не будет просыпаться с утра и думать «ах да, надо не забыть нажать кнопку «Д» в программе Х». Все это ведёт к появлению абсолютно бесполезных программ и неработающих концепций.
Извините что немного не по теме статьи написал, затриггерило :)
Тысячи и тысячи вещей влияют на принятие решений в проекте. Вот, например, amarao верно подмечает прозрачность намерения. Но от этого принцип за тем же KISS не меняется, по моему мнению. Эти лучшие практики про то как писать код являются одним небольшим срезом к успешному проекту. В этой статье речь лишь про то, что вроде как можно этот срез формализировать а уже имея формальные критерии маленького среза можно дальше смотреть на влияние все этих лучших практик на проект.
В статье как раз все идёт к простоте. Но я разделяю вашу точку зрения — «намерение»(intent) в моей команде главенствующий принцип ревью. То есть, код должен реализовывать явное и непротиворечивое намерение, и это намерение должно быть читаемо из кода. Однако, мне кажется, что хоть это сродни простоте, но это все же про лёгкость: simple vs easy.
Вы слышали про skip level one to one? Или про OKR? Если слышали, то вот вам и ответ.
Я одно не пойму, как так получается у вас, что можно делегировать ответственность? Ответственность имеет направленность только вверх — ты можешь принять ответственность за нижестоящих, но не можешь делегировать.
То есть, если у менеджера получается делегировать ответственность в вашей компании то значит менеджер менеджера это позволяет. И вопросы на самом деле к менеджеру менеджеров.
—
Ответственность здесь значит accountability, не responsibility. Responsibility как раз нужно делегировать. Не знаю как лучше перевести это два слова, извините.
С чего это вдруг мощность или тип сознания отличаются? Если сознание это про динамику и к-во элементов, то не имеет значение из чего сделан нейрон. Я не вижу как сознание сделанное из меньшего к-ва элементов может оказаться «мощнее». И, кстати, умение ходить после рождения не коррелирует с сознанием.
Гипотеза про то что сознание это свойство сложных динамических структур очень красива и не нова, но для неё не нужны ни люди ни интернет. Если мы берём эту гипотезу за основу, то сознание в каком-то виде должно быть везде.
В ваших измышлениях, правда, отсутсвует ещё один кусок пазла: скорость протекания реакций. С ростом масштаба (читай размер) системы меняется скорость взаимодействия и, соответсвенно, скорость протекания «мысли» у целого.
Так что может интернет и люди как динамическая система и образуют сознание, но учитывая как недавно эта структура образовалась, то сознание целого ещё даже могло не осознать себя — для него прошёл только один микроскопический сознательный миг.
PS. Если что, есть альтернативна гипотезе о сознании как свойство динамических систем. Я сейчас про современный панпсихизм, в котором тоже все очень интересно.
Да, и это реальная проблема для тасовачных машин. Оказалось что сложно сделать машину которая будет делить колоду на две части в недетерминированном месте и тасовать ее неровно (когда каждая карта слева ложиться на каждую справа). То есть повторять «ошибки» людей, которые, в общем, и делают riffle эффективным.
Riffle конечно же, автокоррекция подвела. Оценка количества итераций которую вы привели это почти она. Bayer ее уточнил по тому как люди тасуют карты и оценка чуть-чуть понизилась до тех самых 7.
Эта статья могла бы быть просто великолепна если бы вы использовали математику из этой публикации https://arxiv.org/pdf/math/0501401.pdf. Jonasson в ней доказал что чтобы хорошо перетасовать колоду способом из статьи нужно минимум N^2 log N (для колоды из N карт) повторений, что чуть-чуть далеко от 64.
Кстати, эта же работа ссылается на другую работу в которой был найден самый эффективный способ тасовки — 7 итераций river shuffle.
Кстати да, есть разница в отношении к типу байка. Субъективно, кажется что к адвенчюрам самое нейтрально-уважительное отношение среди байкеров и автомобилистов. Особенно если это какой-нибудь GS обвешанный со всех сторон.
Как вам уже сказали — это миф. Громкий выхлоп на самом деле может стать причиной аварии.
Буквально в этом сезоне наблюдал как на трассе джиксер с примерно +50-70 перепугал водителя в соседней полосе (тот испугался от резкого падения частоты звука и тупо дернул рулем, хорошо в другую сторону). Эффект Доплера превращают аргументы за громкий выхлоп в аргументы против. А на низкой скорости громкий выхлоп только раздражает всех, включая самого байкера.
Дополню про плохой контакт с дорогой. Еще опасны середины полос всяким ГСМ, мокрая дорожная разметка, металлические люки, брусчатки, лужи и мокрый асфальт особенно в первые минут 20, пока все ГСМ с дороги водой смывает. И все то же самое сухое, но в холод.
А вообще ATGATT, контрастная одежда, постоянное оттачивание навыков оборонительного вождения, ABS, хорошее знание своего байка и поменьше самоуверенности помогут сильно увеличить шансы доехать.
В моём комментарии только моя попытка анализа — моего взгляда на ситуацию там нет. Так откуда вы решили что я считаю что-то проблемой?
Насколько я понимаю, у этого движения есть два направления: равные возможности и права, борьба с гендерным стереотипами в обществе влияющие на выбор молодых девушек.
Из лично моего опыта: с равными возможностями и правами все лучше и лучше. Молодые девушки могут выбирать профессию и на собеседованиях к ним относятся нейтральнее или положительно (позитивная дискриминация). Да вы и сами привели в пример OSS.
А вот вторая проблема более сложна. Предполагается что гендерные стереотипы в обществе давят/давили на молодых девушек и поэтому они не выбирают/выбрали программирование. Как с этим бороться, как менять общественное мнение? Кажется что, придумался только один вариант: менять мнение молодых девушек через положительную дискриминацию, таким образом балансируя стереотипы в обществе. Больше девушек на конференциях, больше девушек на рабочих местах, в общем, больше success stories.
Насколько это хорошо я понятия не имею, через лет 10 будет видно.
Удивительно: а почему вы 10 лет продолжаете так жить (предполагаю что зарплата у вас выросла к 80)? Не интересовались своими опциями на глобальном рынке? Если дело в переезде, то на удаленке тимлид с 10 летным опытом наверняка сможет $100к.
В статье имеется в виду сильный антропный принцип, вы же говорите про слабый антропный принцип.
Есть очень продвинутый https://paw.cloud, нативный на macOS.