А почему если не секрет?
Мне у/за МКАДом не нравится жить прежде всего потому что час на работу ехать надо. Из наблюдений получилось, что 35 минут до работы(от двери до двери) меня вполне устраивают и не воспринимаются сильно хуже чем 10 пешком, а час — уже слишком.
Предполагаю что в однушке на Манхеттене должны быть какие-то весомые минусы, чтобы перебить плюс времени.
У вас некорректная аналогия. Домашнее задание — это скорее уборка квартиры перед ее просмотром.
P.S. Не отказывался смотреть из вежливости, но заранее отбрасывал вариант если мне по тем или иным причинам не нравился подъезд.
Чувствую себя ханжой, но мне кажется, что количество нелитературных слов стоило бы уменьшить. Это как с матом — на нем можно говорить, а можно употреблять для значительного усиления одной мысли.
Ну вот правда, производственный спор о выборе фреймворка можно описать словом «посрались»? У меня подобных конфликтов было ну может штуки 3 за 12 лет и совещанием они не решались, а споров о инженерных решениях — тысячи наверное.
P.S. Сравнение экраноплана с лэндингом трусов понравилось. Часто подобное в голову приходит, когда перекладываю некие данные из одной таблицы в другую, но дело тут далеко не только в совещаниях.
А теперь вопрос: зачем нужна была вся эта вакханалия с назойливым апдейтером десятки? Чего они добились, кроме раздражения пользователей?
В первую очередь безопасности, большое количество некорпоративных пользователей забивало на эти обновления, ибо и так же работает. Например во времена Conficker у нас в офисе из 20 машин незараженной осталась только моя, потому что я ее обновлял.
Наверное мне очень везёт, но пока это самая беспроблемная версия начиная с 98. Но это чисто для меня, я читал посты про различные проблемы у пользователей.
Во всех этих постах не уточняется какой процент пользователей затрагивают эти проблемы. Мне кажется это не вам и мне очень везёт, а им очень не везёт.
Знаете, может быть мне и не повезло просто в жизни, но в моём опыте я никогда не встречал ситуации, чтобы я, долгое время, просто писал бы код или там, юниттесты. Большую часть времени занимает либо отладка, исправление багов, поступивших от пользователей.
Я 90% процентов времени занимаюсь отладкой и исправлением багов, т.е. мы примерно из одного мира (полагаю уровень абстракции у нас сильно разный, у меня выше, у вас — ниже). И мне в мире исправления багов проще с большим количеством простых абстракций, чем с меньшим количеством более сложных.
А не нужна потому что никакая альтернатива. Нужно продолжение. Да — это делает код более сложным, но и, одновременно, более гибким.
Сложность — это плохо. Гибкость — это хорошо. А поскольку вы не можете сделать код одновременно и простым и гибким — то приходится выбирать.
Не могу полностью согласиться. Моя изначальная точка зрения в том, что распределение сложности — это не всегда ради гибкости, это иногда ради уменьшения локальной сложности ценой дополнительных точек отказа. При этом вероятность отказа в каждой отдельной точке снижается, поэтому вероятность отказа всей программы тоже иногда снижается.
Ну да ладно, это больше спор о терминах, чем конструктивный, свою задачу предупредить студентов считаю выполенной.
А вот ваш второй постскриптум у меня почти дословно на стене висел, когда менторством занимался.
Типичные случаи, которые я наблюдаю у себя — код, не задуманный с целью «супергибкости» заметно сложнее удельно, в пересчёте на строку кода — но при этом его гораздо меньше. Часто — на порядок меньше.
Аналогично, мне почти никогда не приходтся гнаться за размером кода, поэтому я чаще распределяю сложность, часто после того как возвращаюсь к ранее написаномму.
Каждые его 100 строк кода обычно действительно проще. Однако суммарно — он содержит как всю неотъемлемую (essential) сложность (сложность-же должна где-то жить), так ещё, допольнительно, и привнесённую (accidental). Он ну никак не может быть проще.
Имеет ли практический смысл эту суммарную сложность вообще рассматривать? Мы же в один момент времени чаще всего работаем с очень ограниченным количеством кода — и эта работа становится проще.
С таким определением вообще невозможно оперировать, так как оно попросту неконструктивно. Что такое «знания»? Как их мерить?
Мне встречаются люди, которые например говорят — «я не знаю как работает наследование в языке XXX, поэтому все что его использует — сложно». Это да — неконструктивно.
P.S. Мне не нравится фраза "… код становится сложнее", потому что ее сейчас прочитает какой-нибудь студент, не вдаваясь в суть и будет считать, что это безусловное зло, а это не так. Но какая-нибудь альтернатива фразе в голову не приходт.
За что ж вы так коллег-то ненавидите, а? Я бы пришиб любого, кто пришел бы ко мне с приветом «а теперь поменяй все свои вызовы нашего микросервиса, потому что мы переписали API». Ну, не пришиб бы, но переписать набело с нуля с сохранением обратной совместимости — заставил бы точно.
Если вы действительно проектируете API так, что потом вы его никогда не изменяете, а только дополняете, то я вам искренне завидую, ибо я и большинство других программистов так не умеют. Сколько сталкивался — все развивающиеся API имеют версии и иногда ломают обратную совместимость. Например в Google Maps API фраза «removes deprecated features, and/or introduces backwards-incompatibilities» встречается чуть ли ни на каждую версию. Даже Windows, на мой взгляд образец обратной совместимости, иногда так делает, особенно в драйверах.
Доказательство тоже нужно правильно написать, что может быть ни разу не просто, а иногда вообще не понятно — возможно ли. Зато, если я правильно понимаю, его состояние часто более детерминировано — либо доказано, либо нет, в отличии от юнит-тестов, которые могут быть неполными. Не забыть обновить помогают административные меры в виде TDD и средства автоматизации, которые не дадут запушить в мастер, если тест сломался.
Кстати вопрос, как выразить в типах корректность функции, которая к моменту времени прибавляет рабочее время в часах и получается момент времени в будущем, отвечающий следующим требованиям: момент времени находится в промежутке с 9:00 до 18:00 в рабочий день, согласно производственному календарю, если момент времени попадает на конец рабочего времени(18:00 например), то его нужно перенести на начало следующего с учетом выходных и праздников(например на 9:00), если добавляемое количество времени меньше либо равно количеству рабочих часов в день(например 8), то добавлять час обеда, если точка отсчета находится в нерабочее время(ночь, выходной), то приводить ее к началу ближайшего рабочего дня, если день сокращенный, то учитывать его как полный. Может еще что-то забыл, давно было, но как вы догадались, это про расчет сроков некоего бизнес-действия.
Эту задачу с наскока пыталось решить три разных человека, все время находились какие-нибудь новые граничные случаи, которые забыли учитывать или ломали старые. Я написал классический юнит-тест и наконец победил ее, но не с первой итерации, потому что как раз не все описывал в юнит-тесте. Но чем тут могут типы помочь — я пока к сожалению даже приблизительно не понимаю, особенно учитывая наличие завимости в виде «производственного календаря».
Проще/сложнее — субъективные понятия, которые непонятно в чем измерять. Код, приспособленный для тестирования, иногда более читаем чем неприспособленный за счет накладываемых на него ограничений. Поэтому он проще. С другой стороны, чтобы написать такой код, нужно придумывать новые абстракции, их имена и связи, что делает написание сложнее.
Например, под сложностью часто подразумевают количество сущностей, которые задействованы в юните кода и которыми нужно оперировать в процессе написания/чтения. Все эти IoC, DI, позднее связывание и прочее позволяют иногда размазать сущности по разным юнитам более равномерно, что снижает их количество в отдельно взятом юните, но скорее всего увеличивают их общее количество на всю программу.
Наши суждения о простоте/сложности строятся на нашем разном опыте, в моем случае программа, написанная в стиле «структурного программирования», — это часто мешанина флагов, пятиэтажных ифов и глобальных переменных, с чем никак не проще работать, чем если то же самое написать с использованием ООП-баззвордов. Встречались и обратные примеры, похожие на FizzBuzz Enterprise Edition, но как-то реже.
UPD. Еще хотелось бы добавить, что некоторые под сложностью подразумевают количество знаний, которое нужно применить для написания/чтения кода, но мне такое измерение не по душе, потому что субъективность здесь возводится в абсолют.
Нет. Если это сложно для свободы слова, то это не значит, что это также сложно для ПДД или еще для чего-то.
Скорость например — измеримый фактор, оскорбленность — нет, вообще может оказаться так, что на одну и ту же фразу один оскорбиться, другой воспримет как похвалу.
Нет, группы нет. Вы её отбираете постфактум. Таким образом можно доказать, что в глобальном потеплении виновато уменьшение пиратов.
А что такое пираты? Не группа ли людей, которые уже совершила конкретные действия(захват суда и/или его груза)?
Пиратов и потепление обычно упоминают, когда путают «после» и «вследствие». Мы о таких отношениях не разговаривали.
Группа после действия не возникает. Она должна возникнуть ДО.
Группа евреев существует независимо от закона и четко определена, более того — связана между собой.
Чтобы призывать к чему-то по отношению к какому-то множеству людей, совершенно не важно когда и как возникла характеристика, по которой это множество отбирается.
Определять допустимость этих призывов — иногда важно, и это может играть ключевую роль.
Потому что вы пришли в тему после комментария и я не понимаю, что в нем не понятного?
Всё, кроме цитаты. Ваша позиция и ее аргументация не понятны. Впрочем, с вами сложно вести диалог, потому что причинно-следственные связи вы не приводите. А на вопросы не отвечаете, если они вам неудобны.
Я так скорее всего так вообще работать не буду, как раз потому что нет возможности в суд. Или буду использовать специализированную площадку с эскроу и арбитражем(который тот же суд, но частный). Если уж очень захочется, то буду риски невыплаты закладывать в цену.
Репутация работает, но дает несколько меньшую защиту. Ее надо откуда-то узнать. И она работает вне зависимости наличия или отсутствия государства.
В общем, соглашусь, что решение для фриланса и работы есть в виде бирж. Еще можно страховки придумать.
Но есть нюанс, лет 15 назад были три крупные и авторитетные биржи rentacoder, elance и odesk. Потом последний скупил остальных и получился по сути монополист. Вопрос, если такое же произойдет при отсутствии гос.судов, то чем этот монополист будет отличаться от государства, за исключением того, что у него цель будет получение прибыли?
P.S. Раз уж пошла такая пьянка, а что анкаповцы предлагают делать с ядерным оружием?
Обвинять друг друга в демагогии считаю не конструктивным, а отстаивать свои методы приведения аргументов слишком трудозатратным, по сему предлагаю закончить. Мир, дружба, пиво.
Да, ложь, извините не совладал с эмоциями. Имел ввиду не показали чем ObamaCare не соответствует вашему определению, которое не особо конфликтует с моим.
Левые в политике (наиболее крайние формы называют ультралевыми или радикально левыми) — традиционное название многих политических направлений и идеологий, целью которых, в частности, являются социальное равноправие (равенство) и улучшение жизненных условий для наименее привилегированных слоёв общества либо полная отмена классового деления общества. Левые выступают за ограничение либо полную отмену частной собственности на средства производства. Они, как правило, стремятся к социальному равенству — выравниванию возможностей для членов разных социальных групп.
ObamaCare по вашему соответствует выделенным стремлениям?
На мой взгляд да, пусть и не очень успешно, но по данным из вики около 20-24млн получили страховку благодаря этому закону.
Если вы так не считаете, пожалуйста, напишите что именно вас не устраивает в законе, чтобы его считать левым, а не просто плохим.
Ну то есть вам всё равно, поэтому левым вы обзываете всё что угодно. Я понял.
Я изначально написал, что считаю левым, что правым. Вы другой интерпретации не предложили.
Подмена тезиса. Где у меня написано, что это выгодно всему бизнесу?
Там где не указана конкретная отрасль. Видите ли можно увеличить налоги, потратить их на одну отрасль, при этом для всех остальных отраслей это не будет выгодно. И да введение такого налога — это чаще всего left-wing закон. (Если спонсируем силовые структуры, то хз какой он left или right).
А, теперь вы переопределяете термин демагогии, как вам выгодно.
А то окажется, в поле «пол» передаётся не 0 или 1, а строка неопределенной длины. И делайте с этим, что хотите — изменить систему у вас уже нет возможности.
Очень характерно, что вам это приходится показывать на пальцах
Вы издеваетесь что ли? То, что вы описали это про типизацию этих данных, а цифры — это все таки значения (да граничные значения вам тоже скажут, но не конкретные).
Очень характерно, что вам приходится это объяснять.
Так на этот вопрос даже другой человек уже ответил. Я не виноват, что для вас богатые — это те, кто не бедные.
Ну если вас смущает только термин «богатые», то ок, пусть будет за счет небедных, т.е. тех кто зарабатывает выше среднего. Я искренне не понимаю, какая разница как их называть, это же просто переменная в коде, которая содержит коллекцию налогоплательщиков.
Ну так объяснение простой — вы их выдумали, поэтому они такие.
Подставьте другие цифры — результат будет тем же: те у кого доход выше среднего заплатили больше налогов, но не получили субсидий, некоторые из тех у кого ниже среднего — субсидии получили, заплатив меньше налогов. Цифры нужны просто для наглядности, не более.
Только это такой же подлог, как выгодный бизнесу закон называть «левым».
Не вижу противоречий между левым и выгодным бизнесу. Даже не смотря на то, что я не очень понимаю, чем всему бизнесу это выгодно, скажем чем он выгоден тому же Google или Lockheed или Walmart?
Нет, вы упираете на выдуманные аргументы, которые я должен как-то типа опровергать с калькулятором на руках. Демагогия. Прямая.
Демагогия — это как раз прицепиться к ничего не значащам конкретным цифрам, которые просто пример для наглядности, и при этом свое видение никак не пояснять ни в цифрах, ни в алгоритмах их расчета, зато обвинять собеседника, что он что-то придумал, хотя это не так. Если вы мои доводы опровергать не хотите, то хотя бы приведите свои, но нет, проще просто оскорблять собеседника.
P.S. Вам когда надо чего-нибудь запрограммировать, вы тоже требуете реальных цифр, вместо тестовых данных, которые к реальности отношения имеют слабое, а если вам их не предоставляют, то называете заказчика демагогом и предлагаете включить локигу?
Мне у/за МКАДом не нравится жить прежде всего потому что час на работу ехать надо. Из наблюдений получилось, что 35 минут до работы(от двери до двери) меня вполне устраивают и не воспринимаются сильно хуже чем 10 пешком, а час — уже слишком.
Предполагаю что в однушке на Манхеттене должны быть какие-то весомые минусы, чтобы перебить плюс времени.
Не лучше ли в этом случае совпровождать свое решение рассказом, поясняя почему оно лучшее, какими были другие варианты и т.п.?
P.S. Не отказывался смотреть из вежливости, но заранее отбрасывал вариант если мне по тем или иным причинам не нравился подъезд.
Ну вот правда, производственный спор о выборе фреймворка можно описать словом «посрались»? У меня подобных конфликтов было ну может штуки 3 за 12 лет и совещанием они не решались, а споров о инженерных решениях — тысячи наверное.
P.S. Сравнение экраноплана с лэндингом трусов понравилось. Часто подобное в голову приходит, когда перекладываю некие данные из одной таблицы в другую, но дело тут далеко не только в совещаниях.
В первую очередь безопасности, большое количество некорпоративных пользователей забивало на эти обновления, ибо и так же работает. Например во времена Conficker у нас в офисе из 20 машин незараженной осталась только моя, потому что я ее обновлял.
Во всех этих постах не уточняется какой процент пользователей затрагивают эти проблемы. Мне кажется это не вам и мне очень везёт, а им очень не везёт.
Я 90% процентов времени занимаюсь отладкой и исправлением багов, т.е. мы примерно из одного мира (полагаю уровень абстракции у нас сильно разный, у меня выше, у вас — ниже). И мне в мире исправления багов проще с большим количеством простых абстракций, чем с меньшим количеством более сложных.
Не могу полностью согласиться. Моя изначальная точка зрения в том, что распределение сложности — это не всегда ради гибкости, это иногда ради уменьшения локальной сложности ценой дополнительных точек отказа. При этом вероятность отказа в каждой отдельной точке снижается, поэтому вероятность отказа всей программы тоже иногда снижается.
Ну да ладно, это больше спор о терминах, чем конструктивный, свою задачу предупредить студентов считаю выполенной.
А вот ваш второй постскриптум у меня почти дословно на стене висел, когда менторством занимался.
Аналогично, мне почти никогда не приходтся гнаться за размером кода, поэтому я чаще распределяю сложность, часто после того как возвращаюсь к ранее написаномму.
Имеет ли практический смысл эту суммарную сложность вообще рассматривать? Мы же в один момент времени чаще всего работаем с очень ограниченным количеством кода — и эта работа становится проще.
Мне встречаются люди, которые например говорят — «я не знаю как работает наследование в языке XXX, поэтому все что его использует — сложно». Это да — неконструктивно.
P.S. Мне не нравится фраза "… код становится сложнее", потому что ее сейчас прочитает какой-нибудь студент, не вдаваясь в суть и будет считать, что это безусловное зло, а это не так. Но какая-нибудь альтернатива фразе в голову не приходт.
Если вы действительно проектируете API так, что потом вы его никогда не изменяете, а только дополняете, то я вам искренне завидую, ибо я и большинство других программистов так не умеют. Сколько сталкивался — все развивающиеся API имеют версии и иногда ломают обратную совместимость. Например в Google Maps API фраза «removes deprecated features, and/or introduces backwards-incompatibilities» встречается чуть ли ни на каждую версию. Даже Windows, на мой взгляд образец обратной совместимости, иногда так делает, особенно в драйверах.
Кстати вопрос, как выразить в типах корректность функции, которая к моменту времени прибавляет рабочее время в часах и получается момент времени в будущем, отвечающий следующим требованиям: момент времени находится в промежутке с 9:00 до 18:00 в рабочий день, согласно производственному календарю, если момент времени попадает на конец рабочего времени(18:00 например), то его нужно перенести на начало следующего с учетом выходных и праздников(например на 9:00), если добавляемое количество времени меньше либо равно количеству рабочих часов в день(например 8), то добавлять час обеда, если точка отсчета находится в нерабочее время(ночь, выходной), то приводить ее к началу ближайшего рабочего дня, если день сокращенный, то учитывать его как полный. Может еще что-то забыл, давно было, но как вы догадались, это про расчет сроков некоего бизнес-действия.
Эту задачу с наскока пыталось решить три разных человека, все время находились какие-нибудь новые граничные случаи, которые забыли учитывать или ломали старые. Я написал классический юнит-тест и наконец победил ее, но не с первой итерации, потому что как раз не все описывал в юнит-тесте. Но чем тут могут типы помочь — я пока к сожалению даже приблизительно не понимаю, особенно учитывая наличие завимости в виде «производственного календаря».
Например, под сложностью часто подразумевают количество сущностей, которые задействованы в юните кода и которыми нужно оперировать в процессе написания/чтения. Все эти IoC, DI, позднее связывание и прочее позволяют иногда размазать сущности по разным юнитам более равномерно, что снижает их количество в отдельно взятом юните, но скорее всего увеличивают их общее количество на всю программу.
Наши суждения о простоте/сложности строятся на нашем разном опыте, в моем случае программа, написанная в стиле «структурного программирования», — это часто мешанина флагов, пятиэтажных ифов и глобальных переменных, с чем никак не проще работать, чем если то же самое написать с использованием ООП-баззвордов. Встречались и обратные примеры, похожие на FizzBuzz Enterprise Edition, но как-то реже.
UPD. Еще хотелось бы добавить, что некоторые под сложностью подразумевают количество знаний, которое нужно применить для написания/чтения кода, но мне такое измерение не по душе, потому что субъективность здесь возводится в абсолют.
Скорость например — измеримый фактор, оскорбленность — нет, вообще может оказаться так, что на одну и ту же фразу один оскорбиться, другой воспримет как похвалу.
А что такое пираты? Не группа ли людей, которые уже совершила конкретные действия(захват суда и/или его груза)?
Пиратов и потепление обычно упоминают, когда путают «после» и «вследствие». Мы о таких отношениях не разговаривали.
Чтобы призывать к чему-то по отношению к какому-то множеству людей, совершенно не важно когда и как возникла характеристика, по которой это множество отбирается.
Определять допустимость этих призывов — иногда важно, и это может играть ключевую роль.
Всё, кроме цитаты. Ваша позиция и ее аргументация не понятны. Впрочем, с вами сложно вести диалог, потому что причинно-следственные связи вы не приводите. А на вопросы не отвечаете, если они вам неудобны.
Репутация работает, но дает несколько меньшую защиту. Ее надо откуда-то узнать. И она работает вне зависимости наличия или отсутствия государства.
В общем, соглашусь, что решение для фриланса и работы есть в виде бирж. Еще можно страховки придумать.
Но есть нюанс, лет 15 назад были три крупные и авторитетные биржи rentacoder, elance и odesk. Потом последний скупил остальных и получился по сути монополист. Вопрос, если такое же произойдет при отсутствии гос.судов, то чем этот монополист будет отличаться от государства, за исключением того, что у него цель будет получение прибыли?
P.S. Раз уж пошла такая пьянка, а что анкаповцы предлагают делать с ядерным оружием?
Да, ложь, извините не совладал с эмоциями. Имел ввиду не показали чем ObamaCare не соответствует вашему определению, которое не особо конфликтует с моим.
ObamaCare по вашему соответствует выделенным стремлениям?
На мой взгляд да, пусть и не очень успешно, но по данным из вики около 20-24млн получили страховку благодаря этому закону.
Если вы так не считаете, пожалуйста, напишите что именно вас не устраивает в законе, чтобы его считать левым, а не просто плохим.
Я изначально написал, что считаю левым, что правым. Вы другой интерпретации не предложили.
Там где не указана конкретная отрасль. Видите ли можно увеличить налоги, потратить их на одну отрасль, при этом для всех остальных отраслей это не будет выгодно. И да введение такого налога — это чаще всего left-wing закон. (Если спонсируем силовые структуры, то хз какой он left или right).
Концентрация на частностях И следующий пункт тоже про ваш метод ведения дискуссии.
Вы издеваетесь что ли? То, что вы описали это про типизацию этих данных, а цифры — это все таки значения (да граничные значения вам тоже скажут, но не конкретные).
Очень характерно, что вам приходится это объяснять.
Ну если вас смущает только термин «богатые», то ок, пусть будет за счет небедных, т.е. тех кто зарабатывает выше среднего. Я искренне не понимаю, какая разница как их называть, это же просто переменная в коде, которая содержит коллекцию налогоплательщиков.
Подставьте другие цифры — результат будет тем же: те у кого доход выше среднего заплатили больше налогов, но не получили субсидий, некоторые из тех у кого ниже среднего — субсидии получили, заплатив меньше налогов. Цифры нужны просто для наглядности, не более.
Не вижу противоречий между левым и выгодным бизнесу. Даже не смотря на то, что я не очень понимаю, чем всему бизнесу это выгодно, скажем чем он выгоден тому же Google или Lockheed или Walmart?
Демагогия — это как раз прицепиться к ничего не значащам конкретным цифрам, которые просто пример для наглядности, и при этом свое видение никак не пояснять ни в цифрах, ни в алгоритмах их расчета, зато обвинять собеседника, что он что-то придумал, хотя это не так. Если вы мои доводы опровергать не хотите, то хотя бы приведите свои, но нет, проще просто оскорблять собеседника.
P.S. Вам когда надо чего-нибудь запрограммировать, вы тоже требуете реальных цифр, вместо тестовых данных, которые к реальности отношения имеют слабое, а если вам их не предоставляют, то называете заказчика демагогом и предлагаете включить локигу?