Вот вы пишете "Комментарий с правой стороны от константы токена не так важен...". А в оригинале написано "The comment on the right-hand side of the token constant is important..." что очень важен. И по смыслу вашего текста дальше видно, что очень даже важен.
Да... "раскройте, чтобы увидеть текст боковой панели" - у нас была совсем небольшая дискуссия на эту тему. Дело в том, что в оригинальной статье эти "вставки" были сделаны в форме сайдбаров. И сначала я думал, что можно написать на спойлерах что-то типа "Нажмите сюда, чтобы увидеть содержимое ACID, BASE и CAP" - но под конец почему то тупанул и просто оформил так, как будто читатель видел оригинал и понимает, что имеется в виду.
И по поводу физической реальности, Вы чертовски правы! И мало того, что свет отраженный от луны достигает нас только через секунду, а свет испускаемый солнцем достигает нас чуть больше, чем за 8 минут, так и скорость распространения импульса по нервной системе тоже не мгновенна! И, если у нас тут потухнет солнце, то я узнаю об этом только через 8 минут, а мой друг, который живет на Альфа Центавре, может об этом так и не узнать за свою короткую жизнь... Он будет продолжать слать мне новогодние открытки и переживать, почему же не приходит обратный ответ, ведь в телескопе все выглядит Ок!
Так, давайте вы сначала попробуете перевести исходную статью в гугл- или яндекс-переводчике, а потом ужу будете утверждать что-то подобное.
А еще лучше, вы просто скажете, что конкретно в нашем тексте вам не понравилось. Возможно мы ошиблись где-то (ведь люди ошибаются), так давайте вместе исправим ошибку.
Извините, что вам не угодил. Хотел первым делом написать, почему я опубликовал перевод такой старой статьи, но вы опередили меня
Итак. Я не нашел ни одной хорошей статьи, которая бы объясняла, откуда взялся такой интересный мейнстрим - навязывать кап-ярлыки базам данных. Особенно страдают реляционные, которым всегда дают CA. Хорошо, но что такое "распределенная система, которая forfeit P?". Решительно никто не может объяснить в RU сегменте, что же это значит Partition Tolerance. А некоторые онлайн IT-школы вообще говорят, что P дано нам от рождения, потому что TCP-IP нам это гарантирует!
Я нашел эту статью чисто случайно, и в ней автор раскрывает все, что так долго путают технические специалисты среднего уровня. Так вот, чтобы прекратить всю эту околесицу, я и взялся за этот перевод. Конечно делал я его не сам. Над переводом работали два человека - мой хороший друг и учитель английского языка - Екатерина Харченко и я (ваш покорный Игорь Меньшенин), как технический специалист.
Мы работали над каждой фразой и выверяли все понятия. Адаптировали в некоторых местах так, чтобы было понятно не только прожженному разработчику. Уверяю вас, что в этом переводе нет ни одного слова, которое бы мы скопировали из гугл- или другого онлайн переводчика, так что я просто думаю, что ваш комментарий проплачен.
rarjpeg просто приклеивал архив после завершающего маркера JPEG файла. Даже если вы зашифруете сообщение, определить, что к файлу "пришиты" какие-то данные легко. вот тут (https://habr.com/ru/company/infowatch/blog/337084/) есть статья в которой описываются алгоритмы обнаружения таких данных
в своей статье я хотел показать, что "спрятать" данные - это только половина дела. необходимо позаботиться об их защите как минимум с помощью шифра или цифровой подписи. и показал юзкейсы
Порядок следования параметров не важен, если значения связаны с параметрами. А вот если наименования параметров и передаваемые значения не имеют сцепки, тогда порядок становится важен. Только давайте я назову это "порядок передаваемых значений". Вот поглядите:
// мне не важно, вот так:
v.Set("server_name", serverName)
v.Set("database_name", databaseName)
// или вот так:
v.Set("database_name", databaseName)
v.Set("server_name", serverName)
Сколько бы ни было параметров в такой логике, напротив каждого я вижу имя параметра и передаваемое значение.
// мне важно вот так
fmt.Sprintf("?database_name=%s&server_name=%s", serverName, databaseName)
А теперь этот пример с двумя параметрами увеличьте мысленно хотя бы до шести параметров, да еще прикольно будет, если в имени каждого будет _name.
Так что - глаза. Мой ответ "глаза мне мешают ошибиться в порядке передаваемых значений".
Не совсем понимаю, где тут "привирание" - Grow(128) - тут происходит выделение буфера памяти - да, это аллокация, а возможно, если не хватит этого буфера, то будет еще одна аллокация
Кешировать параметры никто не собирается - тема статьи не про то, как производительнее конкатенировать строки. А про то, что Sprintf - это плохой способ собрать URL
Ну, это имеет значение только, если процесс происходит вне вашей инфраструктуры. Т.е. браузерная адресная строка и подобное Все URL подключения к базам данных и любым другим сервисам внутри вашей инфраструктуры это нормально переносят. А те, что вне - подключаемся через TLS и снова все ок Т.е., если грубо, то скажу так: на бэкэндщиков это правило не действует =)
Ведь фактически всем безразлично, где вы передаете логин и пароль - самое главное, чтобы это было защищено. А если это в адресной строке браузера - то это уже видно на экране (полагаю, что еще и HTTP прокси увидит, если он есть) - т.е. не секюрно
Ну зачем ставить вопрос так? Доход определяется уровнем знаний - это да.
Я же не сказал "с такой зарплатой Вы точно не Middle", я дал ссылку на интересную статью, где парень подсказывает, как можно себя идентифицировать. Да я работая на Дельфи в 2014 году больше в два раза зарабатывал и миддлом себя не считал.
Эти все ваши "по навыкам я миддл" или "я оцениваю себя как миддл", а где ваши доказательства? Серьезно Java Middle за 35-50 т.р? Вы на какой планете такую ЗП с такими скиллами получаете?
Миддл - это не тот, кто хорошо справляется со своими задачами в рамках своих ежедневных обязанностей. Миддл и в архитектуру в определенных границах умеет. И на вопрос о SOLID принципах не будет бубнить заученную с хабра статью.
Расширять кругозор - это то, чего так не хватает в нашей области. Пусть комментатор попробуется на Миддла в серьезную компанию - он узнает что нужно знать, чтобы стать миддлом. А если пройдет - будет приятно удивлен уровнем дохода и разнообразностью задач.
Приз за самую короткую и бессодержательную статью о принципах SOLID сфоткаете?
"Как правило разработчикам приходится реализовывать новую функциональность, а не менять старую. Так давайте писать код так, чтобы новое было легко писать, а старое — тяжело сломать"
Да нет. В первом комменте я просто рассказал, почему я за постоянный странный парсинг константы. А во втором, я прикинул, что моя придирка к необработанной ошибке на самом деле высосана из пальца. Спасибо за комментарии
Вот вы пишете "Комментарий с правой стороны от константы токена не так важен...". А в оригинале написано "The comment on the right-hand side of the token constant is important..." что очень важен. И по смыслу вашего текста дальше видно, что очень даже важен.
Да... "раскройте, чтобы увидеть текст боковой панели" - у нас была совсем небольшая дискуссия на эту тему. Дело в том, что в оригинальной статье эти "вставки" были сделаны в форме сайдбаров. И сначала я думал, что можно написать на спойлерах что-то типа "Нажмите сюда, чтобы увидеть содержимое ACID, BASE и CAP" - но под конец почему то тупанул и просто оформил так, как будто читатель видел оригинал и понимает, что имеется в виду.
И по поводу физической реальности, Вы чертовски правы! И мало того, что свет отраженный от луны достигает нас только через секунду, а свет испускаемый солнцем достигает нас чуть больше, чем за 8 минут, так и скорость распространения импульса по нервной системе тоже не мгновенна! И, если у нас тут потухнет солнце, то я узнаю об этом только через 8 минут, а мой друг, который живет на Альфа Центавре, может об этом так и не узнать за свою короткую жизнь... Он будет продолжать слать мне новогодние открытки и переживать, почему же не приходит обратный ответ, ведь в телескопе все выглядит Ок!
Так, давайте вы сначала попробуете перевести исходную статью в гугл- или яндекс-переводчике, а потом ужу будете утверждать что-то подобное.
А еще лучше, вы просто скажете, что конкретно в нашем тексте вам не понравилось. Возможно мы ошиблись где-то (ведь люди ошибаются), так давайте вместе исправим ошибку.
Так а кто спорит то? Статья от 2012 года.
Вот только ее нигде не нагуглишь в русском переводе. И это было грустно
Меня беспокоит только это ваше "символ в символ" - вот это вы уже не докажете, если все-таки не нагуглите свою статью.
А можете ссылку дать? А то я гуглю плохо - так и не нашел перевода.
Извините, что вам не угодил. Хотел первым делом написать, почему я опубликовал перевод такой старой статьи, но вы опередили меня
Итак. Я не нашел ни одной хорошей статьи, которая бы объясняла, откуда взялся такой интересный мейнстрим - навязывать кап-ярлыки базам данных. Особенно страдают реляционные, которым всегда дают CA. Хорошо, но что такое "распределенная система, которая forfeit P?". Решительно никто не может объяснить в RU сегменте, что же это значит Partition Tolerance. А некоторые онлайн IT-школы вообще говорят, что P дано нам от рождения, потому что TCP-IP нам это гарантирует!
Я нашел эту статью чисто случайно, и в ней автор раскрывает все, что так долго путают технические специалисты среднего уровня. Так вот, чтобы прекратить всю эту околесицу, я и взялся за этот перевод. Конечно делал я его не сам. Над переводом работали два человека - мой хороший друг и учитель английского языка - Екатерина Харченко и я (ваш покорный Игорь Меньшенин), как технический специалист.
Мы работали над каждой фразой и выверяли все понятия. Адаптировали в некоторых местах так, чтобы было понятно не только прожженному разработчику. Уверяю вас, что в этом переводе нет ни одного слова, которое бы мы скопировали из гугл- или другого онлайн переводчика, так что я просто думаю, что ваш комментарий проплачен.
Спасибо, нам очень важно ваше мнение =)
О каких конкретно конструкциях вы говорите?
Написать много букв можно о чем угодно, подкрепите конкретными примерами. А то пока только вода
А почему вы решили, что flow9 не функциональный язык? По каким маркерам можно определить функциональный язык по вашему?
но ведь это совсем другая история
rarjpeg просто приклеивал архив после завершающего маркера JPEG файла. Даже если вы зашифруете сообщение, определить, что к файлу "пришиты" какие-то данные легко. вот тут (https://habr.com/ru/company/infowatch/blog/337084/) есть статья в которой описываются алгоритмы обнаружения таких данных
в своей статье я хотел показать, что "спрятать" данные - это только половина дела. необходимо позаботиться об их защите как минимум с помощью шифра или цифровой подписи. и показал юзкейсы
кажется, автор не писал, что "это решение лучше"
на мой взгляд, это просто мини обзор
Порядок следования параметров не важен, если значения связаны с параметрами. А вот если наименования параметров и передаваемые значения не имеют сцепки, тогда порядок становится важен. Только давайте я назову это "порядок передаваемых значений". Вот поглядите:
Сколько бы ни было параметров в такой логике, напротив каждого я вижу имя параметра и передаваемое значение.
А теперь этот пример с двумя параметрами увеличьте мысленно хотя бы до шести параметров, да еще прикольно будет, если в имени каждого будет _name.
Так что - глаза. Мой ответ "глаза мне мешают ошибиться в порядке передаваемых значений".
Нет, у нас все просто. Через запятую однотипные параметры, через пробел тип - это Ок
Передать случайно туда другой тип (булев или нулл) не получится - строгая типизация. Компилятор не даст
Не совсем понимаю, где тут "привирание" - Grow(128) - тут происходит выделение буфера памяти - да, это аллокация, а возможно, если не хватит этого буфера, то будет еще одна аллокация
Кешировать параметры никто не собирается - тема статьи не про то, как производительнее конкатенировать строки. А про то, что Sprintf - это плохой способ собрать URL
fmt.Sprintf - это плохой способ собрать URL!
Ну, это имеет значение только, если процесс происходит вне вашей инфраструктуры. Т.е. браузерная адресная строка и подобное
Все URL подключения к базам данных и любым другим сервисам внутри вашей инфраструктуры это нормально переносят. А те, что вне - подключаемся через TLS и снова все ок
Т.е., если грубо, то скажу так: на бэкэндщиков это правило не действует =)
Ведь фактически всем безразлично, где вы передаете логин и пароль - самое главное, чтобы это было защищено. А если это в адресной строке браузера - то это уже видно на экране (полагаю, что еще и HTTP прокси увидит, если он есть) - т.е. не секюрно
Короче, не угадали немного
Ну зачем ставить вопрос так? Доход определяется уровнем знаний - это да.
Я же не сказал "с такой зарплатой Вы точно не Middle", я дал ссылку на интересную статью, где парень подсказывает, как можно себя идентифицировать. Да я работая на Дельфи в 2014 году больше в два раза зарабатывал и миддлом себя не считал.
Эти все ваши "по навыкам я миддл" или "я оцениваю себя как миддл", а где ваши доказательства? Серьезно Java Middle за 35-50 т.р? Вы на какой планете такую ЗП с такими скиллами получаете?
Миддл - это не тот, кто хорошо справляется со своими задачами в рамках своих ежедневных обязанностей. Миддл и в архитектуру в определенных границах умеет. И на вопрос о SOLID принципах не будет бубнить заученную с хабра статью.
Расширять кругозор - это то, чего так не хватает в нашей области. Пусть комментатор попробуется на Миддла в серьезную компанию - он узнает что нужно знать, чтобы стать миддлом. А если пройдет - будет приятно удивлен уровнем дохода и разнообразностью задач.
Если Вы зарабатываете 35-50к. То подумайте - может быть Вы совсем не Middle?
Почитайте тут, как можно немного расширить кругозор:
https://habr.com/ru/company/ruvds/blog/649611/
Осмелюсь предположить, что автор как раз и говорит, как выйти из миддлов в старшие.
Приз за самую короткую и бессодержательную статью о принципах SOLID сфоткаете?
с этой фразой согласен
Да нет. В первом комменте я просто рассказал, почему я за постоянный странный парсинг константы. А во втором, я прикинул, что моя придирка к необработанной ошибке на самом деле высосана из пальца. Спасибо за комментарии
А вообще мы, наверно, можем использовать замыкание вот так:
должно работать ИМХО