Радиаторы на излучение начинают работать от тысячи по цельсию примерно. И у них эффективность зависит от четвёртой степени температуры. Нюанс - в кельвинах. Вот когда начал металл потихоньку светиться, как советский светодиод - вот тогда хоть чуть излучения пошло наружу.
Так что покрасить в чёрный цвет поможет как ленину педикюр. А при эффективных температурах почему-то не хочет надёжно работать электроника. Кожанные мешки вообще бастуют после такого и на работу не выходят.
Естественно, оно ещё и во все стороны светит, включая обшивку корабля и уже от этого защищаться надо. Естественно, должно быть сделано из дико тугоплавкого сплава вольфрама с адамантием. И надо ещё теплоноситель найти такой, чтобы тысяча по цельсию для него было холодно и жидко. Потому что ниже такие радиаторы не охладят. И трубы под такой фреон, чтобы в горячем состоянии его везти охлаждать.
Здесь как раз проблем нет. Синтез, в отличие от распада, не самоподдерживающаяся реакция. Она требует запредельных условий, и в бомбуэ такие условия создают ядерные заряды первой ступени.
Проблем с термоядом две:
Тратить энергии на поддержание реакции меньше, чем результативно снимать с неё же.
Специфическая для космоса проблема, где нет водоёма под рукой. Ну нагрели мы вещество, дальше что? Надо же перепад температур, а у нас разогревается ВЕСЬ корабль и его даже обдуть нечем
Мне вот сатисфактори больше разработку напоминает. Особенно на поздних стадиях ты видишь, что твой проект разросся и состоит из костылей и палок. И случайный затык где-нибудь ставит раком всю систему. И масштабироваться сложно, безумно сложно, потому что в начале ты этого не предусмотрел.
И как в жизни, там есть миллион способов решить одну задачу. Можно кинуть соплю конвеера, а потом об неё спотыкаться, можно провести линию поезда, можно поставить порт для дронов или пустить бегать трактор. Каждый способ специфический и имеет свои ограничения. Почти каждый ресурс имеет несколько способов производства, требуемые ресурсы надо понять откуда лучше везти.
Вообще карты соответствия делают даже англоговорящие разрабы. Просто, чтобы в коде и в обсуждениях с бизнесом термины совпадали.
Но не хотите - не делайте. Кто я такой, чтобы вам указывать, что делать?
Это ваши проблемы будут дальше, когда (или если) вы попадёте в другую компанию, а там будет всё незнакомо. Думаете почему люди стремятся стандартизировать что-то? Вот именно поэтому. Чтобы на одном языке шёл разговор.
Как я уже сказал - международный язык для разработки - английский. Если вы пишете переменные по-русски, то я не имею права вас осуждать. Но осуждаю.
Есть английский язык как стандарт для айти. Что это вообще за вопрос такой был: переведи медицинский термин туда и обратно? Зачем? Как это связано с темой разговора?
Если у вас есть предметная область и вы пишете исходный код для системы, работающей в ней, у вас УЖЕ ЕСТЬ термины, от которых можно отталкиваться. У вас уже есть медицинское обследование. У вас есть производственная травма. Вам рассказать, как перевести на английский термин "после"?
И, пожалуйста, не надо мне тыкать. Может оказаться, что я старше вас лет на 10.
О. Вспомнил, кто вы такой. Отрицатель ООП. Тогда ладно. Мои аргументы бессильны. Сдаюсь.
Ну всмысле как? Ведущий выбирает из двух дверей, какую открыть. Он не открывает дверь, на которую показал игрок.
Две двери, ведущий выбирает из них пустую. Сознательно. Зная, где коза. У двух дверей раньше была вероятность 2/3. Теперь вероятность для них осталась такой же, но из двух дверей закрыта только одна.
Шучу, серьёзный ответ будет: "а так же, как и всем остальным"
И про комментарии в корне не согласен. Если человек не может перевести "save_period", то пусть идёт в дворники. Тот, кто пишет комментарий "период сохранения" тоже пусть в дворники идёт. Комментарий должен быть "Период сохранения в секундах после последнего действия пользователя".
80% - лажа гопоты, 20% - моя лажа. Ну примерно так. В расчёте на строчку кода гопота лажает намного чаще, тесты находят у меня так много ошибок просто потому, что я знаю, что именно надо тестировать.
Если вы не знаете что тестировать значит либо не поняли задачу, либо вам её плохо поставили
Вы наверное работали только в ролях исполнителя, когда вам приносят уже разжёванную задачу. Как бы так вам сказать... Эту задачу нужно ещё создать, порезать на таски и этим тоже кто-то занимается. Потому что бизнес как правило приходит не с задачами, а с проблемами. А ещё есть ресёрч. А ещё есть дискоммуникация.
Поэтому у вас сейчас всё просто. Не надо абсолютизма. TDD - не волшебная пилюля, у него есть границы применимости. Если вы не видите их - значит вы просто слепо верите в TDD.
TDD занимается вопросами как надо писать код, как не надо изучает психиатрия
когда вы уже готовитесь писать решение, но не знаете какая у вас бизнес проблема
Проблема как раз известна. Мне нужно дать решение. Каким оно будет - я пока не знаю. Мне нужно сделать ресёрч. Нужно накидать прототип, проверить, как он решает проблему. Потом переписать, потому что пришла в голову идея получше. Оно сразу не получается найти это решение.
Я не спорю, есть задачи (как правило сильно мельче и сильно детерминированнее), которые можно и нужно делать через TDD. Но у меня вот так. Когда я решаю проблемы конкретных людей, а не железяк, мне нужно показывать прототип конкретным людям и получать фидбек. Мне никакие тесты не скажут, решил я проблему или нет.
У меня такое работает. Но есть нюанс. Код пишу я сам, а тесты пишет гопота. А потом, когда это с треском падает, я иду разбираться, что же не работает - тесты или код. А падает оно примерно всегда.
Когда я начинаю писать функционал, я понятия не имею, как он будет выглядеть. И понятия не имею, как его тестировать. За время разработки функционала его архитектура может поменяться десять раз. Если начинать с тестов, то в каждой итерации надо будет и тесты переделывать. А в конце всё равно окажется, что тестируют они не то и не так.
Я для себя нашёл тот этап, когда наиболее разумно писать тесты. Это когда сложный функционал готов, работает, но ещё не отлажен. Вот тогда можно и подумать, а что и как лучше протестировать. Но это уже ни разу не TDD.
Я вам сказал, что конкретно в этом месте вы говорите неправду. Вы же делаете вывод о моих личных качествах. Здесь есть существенная разница и я прошу больше так не делать. Больше никаких шуток про лечащего врача, ок?
И давайте напомню, с чего началось. Вы сказали, что способ, который я предложил, не годится. И долго доставали аргументы из кармана.
В остатке ваш аргумент: это ИНОГДА не годится, потому что, возможно, вы не согласовали это с ответственными лицами. А может быть вы вообще работаете по контракту с государством и повязаны анусокарательными мерами безопасности.
Тем не менее, я говорил про себя и свою компанию. И я не понимаю, почему большинство компаний не делает техзадачи на основе своей кодобазы. Им ничего не мешает. Взяли кусок, рассмотрели, утвердили для показа кандидатам. В этом нет ничего сложного.
С точки зрения безопасности это лучше. Потому что показанный кусок полностью подконтрольный (да и что кандидат с ним сделает, ну серьёзно?), а когда он станет работником, вам ПРИДЁТСЯ дать ему весь код.
Давайте я вообще вашу логику до абсурда доведу. Есть такой приём. Я говорю, что я люблю шашлык. Что в этом такого?
А вы можете меня обвинить в каннибализме. Потому что ситуации разные бывают и я мог оказаться на острове без животных с тремя товарищами.
Радиаторы на излучение начинают работать от тысячи по цельсию примерно. И у них эффективность зависит от четвёртой степени температуры. Нюанс - в кельвинах. Вот когда начал металл потихоньку светиться, как советский светодиод - вот тогда хоть чуть излучения пошло наружу.
Так что покрасить в чёрный цвет поможет как ленину педикюр. А при эффективных температурах почему-то не хочет надёжно работать электроника. Кожанные мешки вообще бастуют после такого и на работу не выходят.
Естественно, оно ещё и во все стороны светит, включая обшивку корабля и уже от этого защищаться надо. Естественно, должно быть сделано из дико тугоплавкого сплава вольфрама с адамантием. И надо ещё теплоноситель найти такой, чтобы тысяча по цельсию для него было холодно и жидко. Потому что ниже такие радиаторы не охладят. И трубы под такой фреон, чтобы в горячем состоянии его везти охлаждать.
Здесь как раз проблем нет. Синтез, в отличие от распада, не самоподдерживающаяся реакция. Она требует запредельных условий, и в бомбуэ такие условия создают ядерные заряды первой ступени.
Проблем с термоядом две:
Тратить энергии на поддержание реакции меньше, чем результативно снимать с неё же.
Специфическая для космоса проблема, где нет водоёма под рукой. Ну нагрели мы вещество, дальше что? Надо же перепад температур, а у нас разогревается ВЕСЬ корабль и его даже обдуть нечем
А никто не пробовал твиты Трампа прогнать через него? Вдруг Дональд - программист?
Мне вот сатисфактори больше разработку напоминает. Особенно на поздних стадиях ты видишь, что твой проект разросся и состоит из костылей и палок. И случайный затык где-нибудь ставит раком всю систему. И масштабироваться сложно, безумно сложно, потому что в начале ты этого не предусмотрел.
И как в жизни, там есть миллион способов решить одну задачу. Можно кинуть соплю конвеера, а потом об неё спотыкаться, можно провести линию поезда, можно поставить порт для дронов или пустить бегать трактор. Каждый способ специфический и имеет свои ограничения. Почти каждый ресурс имеет несколько способов производства, требуемые ресурсы надо понять откуда лучше везти.
Вообще карты соответствия делают даже англоговорящие разрабы. Просто, чтобы в коде и в обсуждениях с бизнесом термины совпадали.
Но не хотите - не делайте. Кто я такой, чтобы вам указывать, что делать?
Это ваши проблемы будут дальше, когда (или если) вы попадёте в другую компанию, а там будет всё незнакомо. Думаете почему люди стремятся стандартизировать что-то? Вот именно поэтому. Чтобы на одном языке шёл разговор.
Как я уже сказал - международный язык для разработки - английский. Если вы пишете переменные по-русски, то я не имею права вас осуждать. Но осуждаю.
Я не понимаю, почему я издеваюсь.
Есть английский язык как стандарт для айти. Что это вообще за вопрос такой был: переведи медицинский термин туда и обратно? Зачем? Как это связано с темой разговора?
Если у вас есть предметная область и вы пишете исходный код для системы, работающей в ней, у вас УЖЕ ЕСТЬ термины, от которых можно отталкиваться. У вас уже есть медицинское обследование. У вас есть производственная травма. Вам рассказать, как перевести на английский термин "после"?
И, пожалуйста, не надо мне тыкать. Может оказаться, что я старше вас лет на 10.
О. Вспомнил, кто вы такой. Отрицатель ООП. Тогда ладно. Мои аргументы бессильны. Сдаюсь.
Для этого нужно, чтобы saving был отглагольным существительным. Нужно указать, что именно оно сейвит. Как существительное само по себе - это экономия.
Ну всмысле как? Ведущий выбирает из двух дверей, какую открыть. Он не открывает дверь, на которую показал игрок.
Две двери, ведущий выбирает из них пустую. Сознательно. Зная, где коза. У двух дверей раньше была вероятность 2/3. Теперь вероятность для них осталась такой же, но из двух дверей закрыта только одна.
Зачем? Медтермины обычно на латыни, пусть в латыни и остаются. Это общепризнанный общемировой формат
нет, у saving другая семантика. Это слово обозначает экономию
Я в курсе. И назвал бы переменную SaveDelayAfterLastActionSec, ой, простите, тут питоний, значит save_delay_after_last_action_sec
И вообще бы вынес нахер в константы в начало файла. Соответственно, капсом.
Вопрос: а нужен ли мне после этого вообще комментарий?
А никак, бгггг
Шучу, серьёзный ответ будет: "а так же, как и всем остальным"
И про комментарии в корне не согласен. Если человек не может перевести "save_period", то пусть идёт в дворники. Тот, кто пишет комментарий "период сохранения" тоже пусть в дворники идёт. Комментарий должен быть "Период сохранения в секундах после последнего действия пользователя".
Вероятность перебежала с открытой двери на не открытую?
Потому что ведущий открывает одну из двух дверей. Причём ту, которая пустая. Вероятность перетекает в тот момент, когда ведущий ВЫБИРАЕТ пустую дверь.
80% - лажа гопоты, 20% - моя лажа. Ну примерно так. В расчёте на строчку кода гопота лажает намного чаще, тесты находят у меня так много ошибок просто потому, что я знаю, что именно надо тестировать.
Вы наверное работали только в ролях исполнителя, когда вам приносят уже разжёванную задачу. Как бы так вам сказать... Эту задачу нужно ещё создать, порезать на таски и этим тоже кто-то занимается. Потому что бизнес как правило приходит не с задачами, а с проблемами. А ещё есть ресёрч. А ещё есть дискоммуникация.
Поэтому у вас сейчас всё просто. Не надо абсолютизма. TDD - не волшебная пилюля, у него есть границы применимости. Если вы не видите их - значит вы просто слепо верите в TDD.
Нет
Проблема как раз известна. Мне нужно дать решение. Каким оно будет - я пока не знаю. Мне нужно сделать ресёрч. Нужно накидать прототип, проверить, как он решает проблему. Потом переписать, потому что пришла в голову идея получше. Оно сразу не получается найти это решение.
Я не спорю, есть задачи (как правило сильно мельче и сильно детерминированнее), которые можно и нужно делать через TDD. Но у меня вот так. Когда я решаю проблемы конкретных людей, а не железяк, мне нужно показывать прототип конкретным людям и получать фидбек. Мне никакие тесты не скажут, решил я проблему или нет.
У меня такое работает. Но есть нюанс. Код пишу я сам, а тесты пишет гопота. А потом, когда это с треском падает, я иду разбираться, что же не работает - тесты или код. А падает оно примерно всегда.
Когда я начинаю писать функционал, я понятия не имею, как он будет выглядеть. И понятия не имею, как его тестировать. За время разработки функционала его архитектура может поменяться десять раз. Если начинать с тестов, то в каждой итерации надо будет и тесты переделывать. А в конце всё равно окажется, что тестируют они не то и не так.
Я для себя нашёл тот этап, когда наиболее разумно писать тесты. Это когда сложный функционал готов, работает, но ещё не отлажен. Вот тогда можно и подумать, а что и как лучше протестировать. Но это уже ни разу не TDD.
Я вам сказал, что конкретно в этом месте вы говорите неправду. Вы же делаете вывод о моих личных качествах. Здесь есть существенная разница и я прошу больше так не делать. Больше никаких шуток про лечащего врача, ок?
И давайте напомню, с чего началось. Вы сказали, что способ, который я предложил, не годится. И долго доставали аргументы из кармана.
В остатке ваш аргумент: это ИНОГДА не годится, потому что, возможно, вы не согласовали это с ответственными лицами. А может быть вы вообще работаете по контракту с государством и повязаны анусокарательными мерами безопасности.
Тем не менее, я говорил про себя и свою компанию. И я не понимаю, почему большинство компаний не делает техзадачи на основе своей кодобазы. Им ничего не мешает. Взяли кусок, рассмотрели, утвердили для показа кандидатам. В этом нет ничего сложного.
С точки зрения безопасности это лучше. Потому что показанный кусок полностью подконтрольный (да и что кандидат с ним сделает, ну серьёзно?), а когда он станет работником, вам ПРИДЁТСЯ дать ему весь код.
Давайте я вообще вашу логику до абсурда доведу. Есть такой приём. Я говорю, что я люблю шашлык. Что в этом такого?
А вы можете меня обвинить в каннибализме. Потому что ситуации разные бывают и я мог оказаться на острове без животных с тремя товарищами.