Да, мне это тоже известно и я не спорю, что с синтаксической точки зрения это правильно.
Но вот с технической точки зрения вышло так, что вот у нас все запросы, где сначала указывается таблица и затем все остальное, а вот SELECT — он у нас особенный.
Спасибо за статью! На самом деле сам недавно тоже задумывался над кривыми решениями by design, вот некоторые примеры:
SQL
Классический SELECT запрос начинается, как ни странно, со слова SELECT. Однако большинство разработчиов начинают читать такие запросы со слова FROM, чтобы определить источник данных (потому что например столбцов id много, а имена таблиц в схеме уникальны). Почему нельзя было реализовать FROM ... SELECT ... хотя бы как альтернативу - не ясно.
Java Collections
В Java, как и в большинстве языков есть такие коллекции как Map (ключ-значение) и List(список/массив на стероидах). Если в Map обратиться к несуществующему ключу через метод .get(key), то в результате будет возвращено значение null. Однако если в том же самом List обратиться к несуществующему индексу по методу .get(index) то будет IndexOutOfBoundsException.
Хорошо, в той же Map есть метод .getOrDefault(key, default) , может быть он есть в List чтобы вернуть null и не обрабатывать исключение? А такого метода List не реализует!
Java Strings
Думаю у многих возникала необходимость разделить строку на массив строк по какому-то разделителю. В Java за это отвечает метод split(regex):
",".split(",") = String[0]{}
и
"а,".split(",") = String[1]{"а"}
",а".split(",") = String[2]{"", "а"}
но почему нельзя всегда делать:
"а,".split(",") = String[2]{"а", ""}
",".split(",") = String[2]{"",""}
загадка.
Зачем было по-умолчанию реализовывать удаление именно завершающих пустых строк из результирующего массива? Как будто нужно либо удалять все пустые строки, либо не трогать вообще.
Не очень верю алгоритмам и каким-то расчетам, когда на бирже в основном торгуют люди. У большинства этих людей есть психология, задачи на месяц или квартал, необходимости платить ипотеку и покупать жене(или мужу) украшения с премии.
Доходность алгоритма — это прямо как-то мало и даже не бьёт инфляцию, не находите? Rule of thumb, которому меня научили в свое время: Реальная инфляция = Текущая ставка ЦБ — Целевая ставка ЦБ.
И в заключение, если не идти против институциональных инвесторов, придерживаться фундаментальных факторов и быть чаще правым, чем нет, то на российской бирже без проблем можно делать 15-25% годовых даже сейчас (в условиях падающего рынка). А в такие моменты как в 2022, можно было увеличить портфель очень сильно, например мой знакомый получил более 400% годовых потому что сработали страховочные опционы, а интересующие его активы продавались за треть-четверть от их цены до кризиса.
А этом и есть смысл! Действительно существует такой маркетинговый прием.
Специально создаются безликие товары с нарочито неприятными упаковками, чтобы вам не хотелось их покупать. И вы брали более дорогой товар. А напечатать красивую этикетку стоит почти столько же, сколько напечатать неприятную этикетку.
Есть и другие приемы такие как: изменяющиеся скидки, переставление товара в магазине, разобщение товара (когда товары одной категории лежат в разных местах, чтобы вам было сложно сравнивать их) итд.
Эх а я то думал, что в статье расскажут как переопределить ещё и комбинации.
Например хочется мне, чтобы копирование было не только на Ctrl+C, но и на Alt+C, подобно маку Cmd+C. И кроме как через input-remapper решить эту задачу у меня никак не получилось. И то ценой нескольких десятков биндингов.
Не существует хорошей или плохой парадигмы, каждому инструменту свое место. В статье приведены примеры плохого применения ООП. Но с таким же успехом можно привести и показательные примеры применения ООП, или вообще любой другой парадигмы. Вопрос старания и принципиальности.
Есть такая фраза: "use the right tool for the right job". Если использовать инструмент неправильно или в не подходящих условиях, то кто сам себе злобный Буратино?
Тоже были проблемы со спиной, которые мне удалось решить упражнениями в зале.
Ввиду своего хобби нашел и изучил книгу "Физическая подготовка военнослужащих и сотрудников силовых структур" за авторством Евгения Богачева и Александра Арутюнова.
Вы можете резонно спросить, что общего у ИТ специалиста и военнослужащего? Общее у нас — нагрузка на спину, и грамотная тренировка спины есть основа наших профессий.
В книге приведен пример программы тренировок (которому я впрочем следовал, модифицируя под себя) включающий углубленные тренировки мышц-стабилизаторов спины, которые и отвечают за осанку и статическую выносливость.
После пары месяцев тренировок 2-3 раза в неделю по 1-1.5 часа у меня перестала болеть спина, а после года мне удалось достичь осанки, как сказал доктор, "по анатомическому атласу". Не говоря конечно о возросшем уровне общей физической подготовки.
Единственное, если спортивного опыта мало, то я настоятельно рекомендую выполнять все упражнения только с тренером. Потому что большая часть успеха — техника выполнения упражнений, а не поднимаемые веса.
Как разработчик, я разработал себе свод правил деловой переписки:
Ответ на письмо точно будет дан в течение 24 часов с момента получения.
Все митинги должны быть запланированы не менее чем за 24 часа. (Исключение — другие разработчики, но там договариваемся через мессенджер).
Почта проверяется 2 раза в день — в начале и в конце рабочего дня.
Ответы на сообщения в мессенджере будут даны в течении 1 часа с момента получения.
Звонки на мобильный допускаются только в экстраодинарных случаях требующих незамедлительного вмешательства (хакерская атака, деструктивное ПО, пожар итд.)
Потому хоть выделяйте текст фиолетовым в крапинку, хоть ставьте СЕО в копию, оно будет прочтено когда прочтено.
Самое важное, что я осознал за все время работы над проектами — проект должен быть нужен.
Нужен хотя бы самому автору проекта, приносить какую-то пользу. Требуется понимание, что это не "очередной проект в стол", тогда и мотивация будет, и желание заниматься проектом.
Делать проект ради проекта — тухлая идея, к которой очень быстро угаснет интерес.
Статья — хорошая затравка для изучения алгоритмов, однако есть что добавить.
Когда читал секцию сортировок, бросилось в глаза, что отсутствуют обозначения устойчивых сортировок (stable sort), а это очень важное свойство. Очень рекомендую добавить это в таблицу сравнения алгоритмов сортировки.
Почему-то что статьи (эта и прошлая), что комментарии предлагают сделать выбор. Но зачем выбирать, если можно не выбирать и пользоваться сразу и тем, и тем?
Я вот раньше тоже как-то переживал за проекты, (а потом мне прострелили колено), а потом пришло осознание, что никакой код не вечен.
Все мы знаем про жизненные циклы ПО, и самое важное в них — это то, что рано или поздно любой код будет удален.
Хотелось бы дополнить автора, что конечно стоит писать как можно лучший код, оптимальный, элегантный...но когда уже написано 100 костылей, то написать 101 костыль действительно мудрое решение. (◕ᴗ◕)
Тут многие говорят об интересном подходе. Но я увидел просто весьма изобретательную модификацию уже существующего — университетского образования. Автор сместил фокус на сиюминутные потери, а не на глобальные, как с университетом, что весьма изобретательно.
В университете тот же принцип: есть бюджетная основа (ака бесплатно), а есть коммерческая. Попасть на бюджетное место лишь малая толика, главное — удержаться на нем. Если не прикладывать усилий, то в итоге придется платить.
Про остановку кровотечения. Согласен с автором только отчасти.
Если крови немного — то можно обойтись бинтом. Если крови много — жгут, а лучше турникет (он проще, и его нельзя порвать на адреналине).
Если причина кровотечения — застрявший предмет в конечности, то турникет накладывается выше этого участка, не вплотную! Предмет самостоятельно не вынимается, только врачами!
Если кровотечение из конечности сильное, но непонятно откуда, то турникет накладывается как можно выше на конечность.
По сути до прибытия медиков турникета хватит, но если медики будут задерживаться, то турникет надлежит ослаблять каждый час с момента наложения. Если турникет не будет ослаблен в течение 1.5 часа, то человек окончательно потеряет конечность!
Чтобы понять об этом фонде все достаточно просто прочитать его стратегию:
Другими словами предлагается нечто подобное (аналогия с садоводством):
На вкус и цвет фонды разные, но я бы предложил ещё раз подумать и оценить совместимость фонда с инвестпрофилем.
Да, мне это тоже известно и я не спорю, что с синтаксической точки зрения это правильно.
Но вот с технической точки зрения вышло так, что вот у нас все запросы, где сначала указывается таблица и затем все остальное, а вот SELECT — он у нас особенный.
Не вижу проблем ни с INSERT, ни с DELETE, где в начале указывается таблица, а только потом все остальное.
Как будто ничего не мешало реализовать SELECT FROM ... (JOIN ...) VALUES ... (WHERE ...).
По сути выглядит так, как будто с синтаксисом SELECT разработчики SQL просто поленились.
Спасибо за статью! На самом деле сам недавно тоже задумывался над кривыми решениями by design, вот некоторые примеры:
SQL
Классический
SELECTзапрос начинается, как ни странно, со словаSELECT. Однако большинство разработчиов начинают читать такие запросы со словаFROM, чтобы определить источник данных (потому что например столбцовidмного, а имена таблиц в схеме уникальны). Почему нельзя было реализоватьFROM ... SELECT ...хотя бы как альтернативу - не ясно.Java Collections
В Java, как и в большинстве языков есть такие коллекции как
Map(ключ-значение) иList(список/массив на стероидах). Если вMapобратиться к несуществующему ключу через метод.get(key), то в результате будет возвращено значениеnull. Однако если в том же самомListобратиться к несуществующему индексу по методу.get(index)то будетIndexOutOfBoundsException.Хорошо, в той же
Mapесть метод.getOrDefault(key, default), может быть он есть вListчтобы вернутьnullи не обрабатывать исключение? А такого методаListне реализует!Java Strings
Думаю у многих возникала необходимость разделить строку на массив строк по какому-то разделителю. В Java за это отвечает метод
split(regex):",".split(",") = String[0]{}и
"а,".split(",") = String[1]{"а"}",а".split(",") = String[2]{"", "а"}но почему нельзя всегда делать:
"а,".split(",") = String[2]{"а", ""}",".split(",") = String[2]{"",""}загадка.
Зачем было по-умолчанию реализовывать удаление именно завершающих пустых строк из результирующего массива? Как будто нужно либо удалять все пустые строки, либо не трогать вообще.
Не очень верю алгоритмам и каким-то расчетам, когда на бирже в основном торгуют люди. У большинства этих людей есть психология, задачи на месяц или квартал, необходимости платить ипотеку и покупать жене(или мужу) украшения с премии.
Доходность алгоритма — это прямо как-то мало и даже не бьёт инфляцию, не находите? Rule of thumb, которому меня научили в свое время: Реальная инфляция = Текущая ставка ЦБ — Целевая ставка ЦБ.
И в заключение, если не идти против институциональных инвесторов, придерживаться фундаментальных факторов и быть чаще правым, чем нет, то на российской бирже без проблем можно делать 15-25% годовых даже сейчас (в условиях падающего рынка). А в такие моменты как в 2022, можно было увеличить портфель очень сильно, например мой знакомый получил более 400% годовых потому что сработали страховочные опционы, а интересующие его активы продавались за треть-четверть от их цены до кризиса.
А этом и есть смысл! Действительно существует такой маркетинговый прием.
Специально создаются безликие товары с нарочито неприятными упаковками, чтобы вам не хотелось их покупать. И вы брали более дорогой товар. А напечатать красивую этикетку стоит почти столько же, сколько напечатать неприятную этикетку.
Есть и другие приемы такие как: изменяющиеся скидки, переставление товара в магазине, разобщение товара (когда товары одной категории лежат в разных местах, чтобы вам было сложно сравнивать их) итд.
В качестве идемпотентного метода приведен в пример метод DELETE, который возвращает 200 или 404.
Как будто проще всегда возвращать 200, кроме тех случаев, когда в теле ответа передается удаленный объект для восстановления.
Эх а я то думал, что в статье расскажут как переопределить ещё и комбинации.
Например хочется мне, чтобы копирование было не только на Ctrl+C, но и на Alt+C, подобно маку Cmd+C. И кроме как через input-remapper решить эту задачу у меня никак не получилось. И то ценой нескольких десятков биндингов.
Отключите уведомления. Мессенджер всё-таки асинхронное средство связи, можно прочитать сообщение когда удобно.
"Заставь дурака ООП следовать, он FizzBuzzEnterprise напишет."
Не существует хорошей или плохой парадигмы, каждому инструменту свое место. В статье приведены примеры плохого применения ООП. Но с таким же успехом можно привести и показательные примеры применения ООП, или вообще любой другой парадигмы. Вопрос старания и принципиальности.
Есть такая фраза: "use the right tool for the right job". Если использовать инструмент неправильно или в не подходящих условиях, то кто сам себе злобный Буратино?
Тоже были проблемы со спиной, которые мне удалось решить упражнениями в зале.
Ввиду своего хобби нашел и изучил книгу "Физическая подготовка военнослужащих и сотрудников силовых структур" за авторством Евгения Богачева и Александра Арутюнова.
Вы можете резонно спросить, что общего у ИТ специалиста и военнослужащего? Общее у нас — нагрузка на спину, и грамотная тренировка спины есть основа наших профессий.
В книге приведен пример программы тренировок (которому я впрочем следовал, модифицируя под себя) включающий углубленные тренировки мышц-стабилизаторов спины, которые и отвечают за осанку и статическую выносливость.
После пары месяцев тренировок 2-3 раза в неделю по 1-1.5 часа у меня перестала болеть спина, а после года мне удалось достичь осанки, как сказал доктор, "по анатомическому атласу". Не говоря конечно о возросшем уровне общей физической подготовки.
Единственное, если спортивного опыта мало, то я настоятельно рекомендую выполнять все упражнения только с тренером. Потому что большая часть успеха — техника выполнения упражнений, а не поднимаемые веса.
Жаль конечно, что этот мем не попал в статью.
24, но на 24 только 1 место)
Как разработчик, я разработал себе свод правил деловой переписки:
Ответ на письмо точно будет дан в течение 24 часов с момента получения.
Все митинги должны быть запланированы не менее чем за 24 часа. (Исключение — другие разработчики, но там договариваемся через мессенджер).
Почта проверяется 2 раза в день — в начале и в конце рабочего дня.
Ответы на сообщения в мессенджере будут даны в течении 1 часа с момента получения.
Звонки на мобильный допускаются только в экстраодинарных случаях требующих незамедлительного вмешательства (хакерская атака, деструктивное ПО, пожар итд.)
Потому хоть выделяйте текст фиолетовым в крапинку, хоть ставьте СЕО в копию, оно будет прочтено когда прочтено.
Самое важное, что я осознал за все время работы над проектами — проект должен быть нужен.
Нужен хотя бы самому автору проекта, приносить какую-то пользу. Требуется понимание, что это не "очередной проект в стол", тогда и мотивация будет, и желание заниматься проектом.
Делать проект ради проекта — тухлая идея, к которой очень быстро угаснет интерес.
Статья — хорошая затравка для изучения алгоритмов, однако есть что добавить.
Когда читал секцию сортировок, бросилось в глаза, что отсутствуют обозначения устойчивых сортировок (stable sort), а это очень важное свойство. Очень рекомендую добавить это в таблицу сравнения алгоритмов сортировки.
А в чем проблема использовать double boot?
Почему-то что статьи (эта и прошлая), что комментарии предлагают сделать выбор. Но зачем выбирать, если можно не выбирать и пользоваться сразу и тем, и тем?
Я вот раньше тоже как-то переживал за проекты, (а потом мне прострелили колено), а потом пришло осознание, что никакой код не вечен.
Все мы знаем про жизненные циклы ПО, и самое важное в них — это то, что рано или поздно любой код будет удален.
Хотелось бы дополнить автора, что конечно стоит писать как можно лучший код, оптимальный, элегантный...но когда уже написано 100 костылей, то написать 101 костыль действительно мудрое решение. (◕ᴗ◕)
Тут многие говорят об интересном подходе. Но я увидел просто весьма изобретательную модификацию уже существующего — университетского образования. Автор сместил фокус на сиюминутные потери, а не на глобальные, как с университетом, что весьма изобретательно.
В университете тот же принцип: есть бюджетная основа (ака бесплатно), а есть коммерческая. Попасть на бюджетное место лишь малая толика, главное — удержаться на нем. Если не прикладывать усилий, то в итоге придется платить.
Про остановку кровотечения. Согласен с автором только отчасти.
Если крови немного — то можно обойтись бинтом. Если крови много — жгут, а лучше турникет (он проще, и его нельзя порвать на адреналине).
Если причина кровотечения — застрявший предмет в конечности, то турникет накладывается выше этого участка, не вплотную! Предмет самостоятельно не вынимается, только врачами!
Если кровотечение из конечности сильное, но непонятно откуда, то турникет накладывается как можно выше на конечность.
По сути до прибытия медиков турникета хватит, но если медики будут задерживаться, то турникет надлежит ослаблять каждый час с момента наложения. Если турникет не будет ослаблен в течение 1.5 часа, то человек окончательно потеряет конечность!