Обработчик исключений в Котлине — это выражение, вполне себе функциональный и надёжный подход. Вот только обрабатывать ошибки не обязательно. Что роняет всю надёжность на ноль.
Возможно, напишу банальщину и вызову массу споров, но выскажу свое мнение. Проблема checked / unchecked исключений хорошо прослеживается в разработке на java.
Архитекторы java следовали простой логике:
— checkеd исключения рассматриваются как ошибки, обрабатывая которые систему можно вернуть в консистентное состояние: например, не найден файл настроек по какому-то пути, давайте найдем его по другому пути, или при чтении произошла ошибка на сети, давайте переподключимся к удаленному хосту и попробуем снова; такие ошибки разработчик должен или явно обработать, или прокинуть на уровень выше;
— unchecked исключения рассматриваются как ошибки уровня виртуальной машины (Error) или ошибки разработчика, который не выполняет контракт при использовании некоторого api (RuntimeException); такие ошибки не надо обрабатывать явно, поскольку нет гарантий, что их можно исправить.
И вроде в этом разделении все выглядит хорошо, пока дело не доходит до массового использования. Чем больше подключаемых библиотек, тем больше своих checked исключений, тем больше вопросов: — А можем ли мы вообще что-то исправить, если отловим? Чаще всего ответ: — Нет, — и разработчики прокидывают исключения на уровень выше, а там на уровень выше и т.д. Писать длинные определения throws у методов с перечислением десятков типов исключений мало кто хочет, и тогда, поддавшись соблазну, люди пишут throws Exception. Все, идея разделения исключений сходит на нет.
Кроме того, единожды объявив метод в какой-то библиотеке, вы обязаны поддерживать его сигнатуру, иначе клиенты вашей библиотеки не смогут безопасно ее использовать.
По этой и другим причинам все больше библиотек и фреймворков стали определять свои типы исключений как unchecked, наследуясь от RuntimeException. Это упрощает поддержку, это упрощает рефакторинг, это упрощает разработку кода.
Скорее всего потому Kotlin, как развитие яп java, и придерживается этой идеологии.
Не пойму, почему люди заминусили человека выше, меня тоже смутила эта «игра» цифрами.
Если прибыль (или именно доход?) в 30к$/месяц был разовая, то, возможно, стоило указать вилку или среднее значение. Потому как иначе выглядит довольно странно: вроде бы жили припеваючи, но потом ввязались в многолетний затратный проект.
Двояко все.
С одной стороны, система наивного рейтинга непоказательна, и речь не только про Яндекс.Такси:
– зачастую оценки ставятся «с потолка»,
– хороший сервис воспринимается как должное, а оцениваются только «ошибки» сервиса,
– оценки сугубо субъективны по определению и в целом для вас не релевантны,
– люди эмоциональны и обидчивы, что может приводить к намеренному поднятию волны гнева,
– не все люди пытаются вникнуть в суть проблем, и порой проблемы возникают на ровном месте из-за простого недопонимания…
С другой стороны, система обратной связи как таковая нужна, чтобы понимать насколько ответственно и качественно водитель и пассажир исполняют свои роли, фиксировать случаи нарушения и предпринимать какие-то действия по улучшению сервиса.
На месте Яндекса я бы собирал обратную связь и делал суждения в разрезе вида нарушения.
К примеру, если Х% пассажиров указали, что в салоне машины неприятный запах, то возможно это правда и стоит разобраться в ситуации. Но это не является критичным фактором для выполнения водителем своих обязанностей.
Проверил на виртуалке ссылки и инсталлеры для skype, отображаемые в рекламных блоках Яндекс.Директ.
Сайт maombi.store. Установщик предлагает установить Яндекс.Браузер (можно отказаться) и Аваст Антивирус (даже если отказаться, все равно установит). Далее идет установка старого дистрибутива Skype 7.4.
Сайты softrary.ru, softcatalog.ru. Аналогично maombi.store с тем отличием, что от Аваста можно отказаться и версия skype уже более новая 8.4.
Сайт epicapps.ru. Установщик предлагает создать на рабочем столе ярлыки на игры WorldOfTanks и т.п. (можно отказаться). Без спроса устанавливает Яндекс.Браузер и помощника Алису. Далее идет установка Skype 8.49.
Сайт skype-msetup.ru. Загружается установщик программ, с помощью которого можно поставить разные браузеры, скайп и прочее. Дистрибутив skype тянет с оригинального сайта.
Сайты iowin.net, mobile-appster.ru по клику на ссылке «Скачать» редиректят на страницу установки Яндекс.Браузер.
К взлому по радужным таблицам способ может и останется столь же стойким, но вот для перебора по словарю / брутфорсу становится менее стойким. Поскольку при компрометации соли и хэша пароля в случае склейки соли спереди, можно «предвычислить» значение хэша, и стойкость пароля становится такой же как и без соли.
Обычно, если таблицы в схемах одноименные, то и структура у них одинаковая
Более чем спорное утверждение. Ваш случай имеет место быть, но он скорее исключение, чем правило.
Почему таблицы могут иметь одинаковое название, но разную структуру? Например, потому что имеют одно название термина, но в разных доменных областях: заявка на подключение, заявка на обслуживание, заявка на отказ и т.д. Да, можно было бы поименовать таблицы с префиксом равным имени домена, но куда логичней создать отдельные схемы с именем домена и сгруппировать объекты бд в рамках этих схем.
Во-первых, одним и тем же запросам по разным схемам в рамках одной базы он присваивает разные QueryId. То есть если сначала сделать SET search_path = '01'; SELECT * FROM user LIMIT 1;, а потом SET search_path = '02'; и такой же запрос
Не совсем понял, чем же это плохо, что будут разные queryId?
По-моему это логично, если вы выполняете select * from user в схеме 01, то будет найдена таблица в этой схеме 01.user, а если выполняете в схеме 02, то 02.user. Более, чем вероятно, что это разные по структуре таблицы с разным набором индексов, констрейнтов, триггеров. Или я что-то не так понял?
«Соль» нужна для увеличения стойкости пароля к перебору по словарю / брутфорсом. Если склеивать «соль» в начало пароля, то вся суть «соли» теряется, т.к. можно предварительно вычислить значение хэш-функции для данной «соли».
Хорошая статья для новичков, но позвольте вас дополнить для полноты картины:
1. Пропущены \d \D в таблице классов символов
2. Незахватывающие шаблоны (?:...)
3. Look-behind шаблоны (?<=...) и (?<!...)
4. Для look-ahead не упомянут вариант с отрицанием (?!...)
5. Установка модификаторов внутри шаблона, например (?isu)
6. Ссылка на ранее захваченный шаблон (["'])([^\1]*)\1
7. Жадность квантификаторов (...)*?
8. Рекурсивные шаблоны
Никто не задавался вопросом, зачем в ByteArrayOutputStream добавлен метод writeBytes(byte[]), который делает ровно то же, что и унаследованный от OutputStream метод write(byte[])?
Тут каждому свое, по мне так express куда более удобен чем koa.
Socket.io морально устарел, когда-то он предоставлял кроссбраузерную абстракцию, сейчас это ненужная зависимость.
Если забыть о jvm, gc, наследии java 1.1 и прочей мишуре, в чем вы видите проблемы java касательно языковых конструкций, системы типов и т.п.?
Не холивара ради, просто мне интересен взгляд со стороны.
Приведите пример, когда виртуальные методы это плохо, когда происходит вызов не актуальной реализации метода (программист зачем-то же переопределял метод), а реализации, определяемой типом указателя / ссылки?
Вы в свою очередь предлагаете сделать еще одну джаву.
В своем комментарии я приводил примеры из java, groovy, dart, php, c#, js, но вы увидели только первое.
Скажите, какой цели вы добивались, создавая пост: получить замечания и критику, указания на недочеты и неудобство? или чтобы потешить свое самолюбие, глядите какой я молодец, сделал еще один c/rust?
Ключевое слово необходимо для упрощения синтаксического разбора.
Одна из самых больших ошибок при разработке ПО, когда делают упущения ради простоты реализации. Как мне кажется, новый ЯП должен не только покрывать недостающий в других ЯП функционал, но и упрощать синтаксис, уменьшать уровень входа для разработчиков.
Я бы пошел по пути groovy / dart / etc, сделав указание типа опциональным и добавив автовыведение типов, т.е.
Названия типов я бы взял из java, да кому-то нравятся сокращения, но неужели f64 более понятен, чем double?
Для часто используемых конструкций добавил бы литералы – массивы/коллекции [], множества {}, хэш-таблицы {:},
Из новых операторов я бы добавил null-safe оператор obj?.attr, может быть cascade оператор… как в dart'е, elvis-оператор ?:.
Систему типов взял бы из java – все методы виртуальные, т.к. в большинстве случаев это и ожидается в ООП, а для статичных методов, пожалуйста, static. Так же добавил бы в систему типов trait'ы.
На уровне класса оперировал понятиями свойств (как c#, groovy, dart) – доступ к значению поля через автогенерируемые getter / setter, но с возможностью переопределить эти методы.
Возможно, стоило бы добавить функции как объекты первого порядка. Возможно использовать понятие замыканий и указывать замыкаемые перемненые через use(..) как в php.
Для синхронизации потоков стоит или на уровне ЯП определить конструкции типа synchronized блоков / volatile, либо добавить в sdk семафоры / мютексы / атомики, которые бы обеспечивали корректную модель памяти.
В конечном счете, чем больше ЯП вы проанализируете, тем более точное представление о проблемах получите. В текущем виде ваш ЯП больше поход на среднее между rust/c++, думаю, вы не этого изначально добивались.
не большинство… сколько лет уже пророчат (и будут пророчить) смерть физическим накопителям и локальным копиям медиа-контента, но, как мне кажется, такого не произойдет никогда… а все по тому, что у всех вкусы разные, и собрать полную базу всего всего медиа-контента (пусть он даже раскидан по множеству сервисов) просто нереально…
У Debian есть slim сборка, в которой вырезаны лишние зависимости и утилиты. Аналогичные сборки есть у дистрибутивов на основе debian.
К примеру образ на alpine python:3.7-rc-alpine весит 94,5Мб, а образ на debian 9 slim python:3.7-rc-slim всего 143Мб, что не многим больше.
Не соглашусь. По моему опыту nginx + php-fpm оказался более производителен, чем apache + mod-php. У apache давние проблемы с использованием ресурсов, выдачей статики и запуском cgi. Nginx же умело использует мощности самой системы (epoll, sendfile).
Если хочется бенчмарков, в google можно найти несколько хороших обзоров.
Возможно, напишу банальщину и вызову массу споров, но выскажу свое мнение. Проблема checked / unchecked исключений хорошо прослеживается в разработке на java.
Архитекторы java следовали простой логике:
— checkеd исключения рассматриваются как ошибки, обрабатывая которые систему можно вернуть в консистентное состояние: например, не найден файл настроек по какому-то пути, давайте найдем его по другому пути, или при чтении произошла ошибка на сети, давайте переподключимся к удаленному хосту и попробуем снова; такие ошибки разработчик должен или явно обработать, или прокинуть на уровень выше;
— unchecked исключения рассматриваются как ошибки уровня виртуальной машины (Error) или ошибки разработчика, который не выполняет контракт при использовании некоторого api (RuntimeException); такие ошибки не надо обрабатывать явно, поскольку нет гарантий, что их можно исправить.
И вроде в этом разделении все выглядит хорошо, пока дело не доходит до массового использования. Чем больше подключаемых библиотек, тем больше своих checked исключений, тем больше вопросов: — А можем ли мы вообще что-то исправить, если отловим? Чаще всего ответ: — Нет, — и разработчики прокидывают исключения на уровень выше, а там на уровень выше и т.д. Писать длинные определения throws у методов с перечислением десятков типов исключений мало кто хочет, и тогда, поддавшись соблазну, люди пишут throws Exception. Все, идея разделения исключений сходит на нет.
Кроме того, единожды объявив метод в какой-то библиотеке, вы обязаны поддерживать его сигнатуру, иначе клиенты вашей библиотеки не смогут безопасно ее использовать.
По этой и другим причинам все больше библиотек и фреймворков стали определять свои типы исключений как unchecked, наследуясь от RuntimeException. Это упрощает поддержку, это упрощает рефакторинг, это упрощает разработку кода.
Скорее всего потому Kotlin, как развитие яп java, и придерживается этой идеологии.
Не забываем про present progressive и т.п. формы.
Будь здесь глагол герундием вышло бы: «Я есть чтение» )))
Если прибыль (или именно доход?) в 30к$/месяц был разовая, то, возможно, стоило указать вилку или среднее значение. Потому как иначе выглядит довольно странно: вроде бы жили припеваючи, но потом ввязались в многолетний затратный проект.
С одной стороны, система наивного рейтинга непоказательна, и речь не только про Яндекс.Такси:
– зачастую оценки ставятся «с потолка»,
– хороший сервис воспринимается как должное, а оцениваются только «ошибки» сервиса,
– оценки сугубо субъективны по определению и в целом для вас не релевантны,
– люди эмоциональны и обидчивы, что может приводить к намеренному поднятию волны гнева,
– не все люди пытаются вникнуть в суть проблем, и порой проблемы возникают на ровном месте из-за простого недопонимания…
С другой стороны, система обратной связи как таковая нужна, чтобы понимать насколько ответственно и качественно водитель и пассажир исполняют свои роли, фиксировать случаи нарушения и предпринимать какие-то действия по улучшению сервиса.
На месте Яндекса я бы собирал обратную связь и делал суждения в разрезе вида нарушения.
К примеру, если Х% пассажиров указали, что в салоне машины неприятный запах, то возможно это правда и стоит разобраться в ситуации. Но это не является критичным фактором для выполнения водителем своих обязанностей.
Сайт maombi.store. Установщик предлагает установить Яндекс.Браузер (можно отказаться) и Аваст Антивирус (даже если отказаться, все равно установит). Далее идет установка старого дистрибутива Skype 7.4.
Сайты softrary.ru, softcatalog.ru. Аналогично maombi.store с тем отличием, что от Аваста можно отказаться и версия skype уже более новая 8.4.
Сайт epicapps.ru. Установщик предлагает создать на рабочем столе ярлыки на игры WorldOfTanks и т.п. (можно отказаться). Без спроса устанавливает Яндекс.Браузер и помощника Алису. Далее идет установка Skype 8.49.
Сайт skype-msetup.ru. Загружается установщик программ, с помощью которого можно поставить разные браузеры, скайп и прочее. Дистрибутив skype тянет с оригинального сайта.
Сайты iowin.net, mobile-appster.ru по клику на ссылке «Скачать» редиректят на страницу установки Яндекс.Браузер.
Более чем спорное утверждение. Ваш случай имеет место быть, но он скорее исключение, чем правило.
Почему таблицы могут иметь одинаковое название, но разную структуру? Например, потому что имеют одно название термина, но в разных доменных областях: заявка на подключение, заявка на обслуживание, заявка на отказ и т.д. Да, можно было бы поименовать таблицы с префиксом равным имени домена, но куда логичней создать отдельные схемы с именем домена и сгруппировать объекты бд в рамках этих схем.
Не совсем понял, чем же это плохо, что будут разные queryId?
По-моему это логично, если вы выполняете select * from user в схеме 01, то будет найдена таблица в этой схеме 01.user, а если выполняете в схеме 02, то 02.user. Более, чем вероятно, что это разные по структуре таблицы с разным набором индексов, констрейнтов, триггеров. Или я что-то не так понял?
«Соль» нужна для увеличения стойкости пароля к перебору по словарю / брутфорсом. Если склеивать «соль» в начало пароля, то вся суть «соли» теряется, т.к. можно предварительно вычислить значение хэш-функции для данной «соли».
1. Пропущены \d \D в таблице классов символов
2. Незахватывающие шаблоны (?:...)
3. Look-behind шаблоны (?<=...) и (?<!...)
4. Для look-ahead не упомянут вариант с отрицанием (?!...)
5. Установка модификаторов внутри шаблона, например (?isu)
6. Ссылка на ранее захваченный шаблон (["'])([^\1]*)\1
7. Жадность квантификаторов (...)*?
8. Рекурсивные шаблоны
Socket.io морально устарел, когда-то он предоставлял кроссбраузерную абстракцию, сейчас это ненужная зависимость.
Не холивара ради, просто мне интересен взгляд со стороны.
В своем комментарии я приводил примеры из java, groovy, dart, php, c#, js, но вы увидели только первое.
Скажите, какой цели вы добивались, создавая пост: получить замечания и критику, указания на недочеты и неудобство? или чтобы потешить свое самолюбие, глядите какой я молодец, сделал еще один c/rust?
Одна из самых больших ошибок при разработке ПО, когда делают упущения ради простоты реализации. Как мне кажется, новый ЯП должен не только покрывать недостающий в других ЯП функционал, но и упрощать синтаксис, уменьшать уровень входа для разработчиков.
Я бы пошел по пути groovy / dart / etc, сделав указание типа опциональным и добавив автовыведение типов, т.е.
Названия типов я бы взял из java, да кому-то нравятся сокращения, но неужели f64 более понятен, чем double?
Для часто используемых конструкций добавил бы литералы – массивы/коллекции [], множества {}, хэш-таблицы {:},
Из новых операторов я бы добавил null-safe оператор obj?.attr, может быть cascade оператор… как в dart'е, elvis-оператор ?:.
Систему типов взял бы из java – все методы виртуальные, т.к. в большинстве случаев это и ожидается в ООП, а для статичных методов, пожалуйста, static. Так же добавил бы в систему типов trait'ы.
На уровне класса оперировал понятиями свойств (как c#, groovy, dart) – доступ к значению поля через автогенерируемые getter / setter, но с возможностью переопределить эти методы.
Возможно, стоило бы добавить функции как объекты первого порядка. Возможно использовать понятие замыканий и указывать замыкаемые перемненые через use(..) как в php.
Для синхронизации потоков стоит или на уровне ЯП определить конструкции типа synchronized блоков / volatile, либо добавить в sdk семафоры / мютексы / атомики, которые бы обеспечивали корректную модель памяти.
В конечном счете, чем больше ЯП вы проанализируете, тем более точное представление о проблемах получите. В текущем виде ваш ЯП больше поход на среднее между rust/c++, думаю, вы не этого изначально добивались.
К примеру образ на alpine python:3.7-rc-alpine весит 94,5Мб, а образ на debian 9 slim python:3.7-rc-slim всего 143Мб, что не многим больше.
Если хочется бенчмарков, в google можно найти несколько хороших обзоров.