Я согласен с тем, что прозрачность в компании важна: если понимать под ней понимание того, что вообще мы делаем, над чем работаем, что будем делать завтра. Так действительно комфортнее работать.
Но я не могу согласиться с выводами статьи. То, что в компаниях с большей "прозрачностью" согласно опросам меньше текучка, не значит причинно-следственной связи: оба эти фактора могут быть следствием, например, сильного и адекватного менеджмента, эффективной бюрократии и организационной структуры.
Вот тоже сомневаюсь, что такие меры разумны. Смотрю тут в комментариях многие хотят поиграть в войнушку, но нападение пиратов - это один из рисков для судовладельца. Наличие оружия на судне, гипотетически, увеличивает шансы на успешное отражение атаки (при условии решулярных тренировок), но создаёт свои риски (например, кому-то из команды "сорвало крышу" через 2 месяца плавания). Какой из рисков выше - ещё неизвестно.
Вместо HttpWebRequest в современном .NET рекомендуется использовать новый класс HttpClient , вот тут подробнее о различиях. Также сразу обращаю внимание, что экземпляр HttpClientлучше переиспользовать.
Также сильно бросается в глаза множество неочевидных условий в ProxyClass : я бы предложил заняться рефакторингом, чтобы уменьшить вложенность кода, а также переименовать поля и переменные, чтобы не требовалось читать комментарии для понимания происходящего.
Про goto выше уже написали. Я бы не стал экономить на строках кода, и выделил бы отдельный метод, например private string EnsureTrailingZero(string rawInn), который бы инкапсулировал логику проверки "утерянного" нуля в начале.
Тут еще можно понять, если автор полагается на то что в QR-кодах используется только с www. Но вот неумение пользоваться регулярками - уже создаёт дыру.
А вот например такой wwwxgosuslugi.ru , полагаю, пройдет - ведь точки не экранированы, и означают любой символ (хотя я не спец в джаве, может быть там как-то по-другому работает)
но я не психанул-ушёл как автор, а собрал совещание с начальством и сказал - не могу, давайте чего попроще! На что получил весьма адекватный ответ
Вот кстати да, скольких проблем и переживаний можно было бы избежать, если бы люди меньше боялись подойти и сказать ртом о своих проблемах. Побоялся бы подойти - через какое-то время получились бы сорваны сроки, негатив.
И кстати, по моим (не очень репрезентативным) наблюдениям, надстройки на VSTO встречаются чаще, чем на новом JS API. Тем более что VSTO - достаточно зрелая и устоявшаяся технология, а вот в JS API, например, несколько лет назад при обновлении версии они очень сильно изменили механику некоторых вызовов, что усложнило жизнь разработчиков: например, вопросов на stackoverflow и так мало, так часть из них относится к старому апи и более неприменима.
В том-то и дело, что мы поздравляли друг друга "с новым две тысячи двадцать вторым годом". С начала нашей эры прошло две тысячи двадцать один год и 10 дней.
Просто надо учесть, что года, месяца и дни мы называем порядковыми чилительными (первое января, две тысячи первый год), а часы, минуты или секунды - количественными (пятнадцать часов двадцать минут, а идёт двадцать первая минута шестнадцатого часа).
Это какая-то зависимость кол-ва комментариев от кол-ва строк? Почему она обратная?
Практика показывает, что когда ты просишь коллегу посмотреть merge request на 50-100 строк, он сможет погрузиться в предлагаемые изменения, и наверняка оставит комментарии со своими предложениями.
Начиная с какого-то объёма, погружаться в содержимое MR становится всё труднее, и в конечном счёте его либо завернут с просьбой вливать по частям, либо вольют и так, без замечаний (если есть доверие к автору и подстраховка в виде CI и тестовой среды, например).
В масштабной системе, где много взаимодействующих компонентов, случаются трудноуловимые баги, которые даже воспроизвести непросто. И действительно, можно провести много дней, просто в попытках воспроизвести локально проблему, которая возникает только на "проде" в полнолуние по нечётным месяцам.
Поддерживаю, было бы неплохо, если такая функция будет встроенной в клиент. Тем более, что боты для распознавания уже существуют, например silero_audio_bot (сам пользуюсь)
любой контр-оффер задержит специалиста максимум на полгода
Слишком категорично. Вот мой пример: прошлой весной всерьёз собрался уходить, но когда позвонил тимлиду увольняться, предложили контроффер +20% к текущей ЗП. С тех пор и тимлид тот ушёл, а я до сих пор на этом же месте, больше полутора лет (правда, последние пару месяцев странные вещи творятся по организационной части, так что подумываю таки об уходе).
Я согласен с тем, что прозрачность в компании важна: если понимать под ней понимание того, что вообще мы делаем, над чем работаем, что будем делать завтра. Так действительно комфортнее работать.
Но я не могу согласиться с выводами статьи. То, что в компаниях с большей "прозрачностью" согласно опросам меньше текучка, не значит причинно-следственной связи: оба эти фактора могут быть следствием, например, сильного и адекватного менеджмента, эффективной бюрократии и организационной структуры.
Вот тоже сомневаюсь, что такие меры разумны. Смотрю тут в комментариях многие хотят поиграть в войнушку, но нападение пиратов - это один из рисков для судовладельца. Наличие оружия на судне, гипотетически, увеличивает шансы на успешное отражение атаки (при условии решулярных тренировок), но создаёт свои риски (например, кому-то из команды "сорвало крышу" через 2 месяца плавания). Какой из рисков выше - ещё неизвестно.
Вспомнился старый анекдот про совет и консультацию
- Саша, хотел у тебя спросить. Задача вот какая...
- Погоди, погоди, тебе совет или консультацию?
- А в чем разница?
- Совет бесплатный, консультация за деньги.
- Совет, конечно!
- Мой тебе совет: запишись на консультацию.
В первоначальной фразе имеется в виду что JS можно воспринимать как подмножество TS - то есть JS-код можно интерперетировать как валидный TS
Вместо
HttpWebRequestв современном .NET рекомендуется использовать новый классHttpClient, вот тут подробнее о различиях. Также сразу обращаю внимание, что экземплярHttpClientлучше переиспользовать.Также сильно бросается в глаза множество неочевидных условий в
ProxyClass: я бы предложил заняться рефакторингом, чтобы уменьшить вложенность кода, а также переименовать поля и переменные, чтобы не требовалось читать комментарии для понимания происходящего.Про goto выше уже написали. Я бы не стал экономить на строках кода, и выделил бы отдельный метод, например
private string EnsureTrailingZero(string rawInn), который бы инкапсулировал логику проверки "утерянного" нуля в начале.Win 10, Chrome - работает некорретно
Тут еще можно понять, если автор полагается на то что в QR-кодах используется только с www. Но вот неумение пользоваться регулярками - уже создаёт дыру.
Да, ваша правда, не увидел что там $ и ^
А вот например такой wwwxgosuslugi.ru , полагаю, пройдет - ведь точки не экранированы, и означают любой символ (хотя я не спец в джаве, может быть там как-то по-другому работает)
По идее должно быть так:
То есть проверки нет. Например, я регистрирую домен example.club, на нём делаю поддомен www.gosusugi.ru.example.club - и оно успешно проходит проверку
А ссылка может быть произвольной?
Вот кстати да, скольких проблем и переживаний можно было бы избежать, если бы люди меньше боялись подойти и сказать ртом о своих проблемах. Побоялся бы подойти - через какое-то время получились бы сорваны сроки, негатив.
И кстати, по моим (не очень репрезентативным) наблюдениям, надстройки на VSTO встречаются чаще, чем на новом JS API. Тем более что VSTO - достаточно зрелая и устоявшаяся технология, а вот в JS API, например, несколько лет назад при обновлении версии они очень сильно изменили механику некоторых вызовов, что усложнило жизнь разработчиков: например, вопросов на stackoverflow и так мало, так часть из них относится к старому апи и более неприменима.
Кстати, пользуясь случаем, порекламирую свою опен-сорс надстройку на VSTO для Excel, может быть, будет кому-нибудь полезной.
В том-то и дело, что мы поздравляли друг друга "с новым две тысячи двадцать вторым годом". С начала нашей эры прошло две тысячи двадцать один год и 10 дней.
Просто надо учесть, что года, месяца и дни мы называем порядковыми чилительными (первое января, две тысячи первый год), а часы, минуты или секунды - количественными (пятнадцать часов двадцать минут, а идёт двадцать первая минута шестнадцатого часа).
Как-то Вы поторопились всё-таки, пока что двадцать второй только)
Практика показывает, что когда ты просишь коллегу посмотреть merge request на 50-100 строк, он сможет погрузиться в предлагаемые изменения, и наверняка оставит комментарии со своими предложениями.
Начиная с какого-то объёма, погружаться в содержимое MR становится всё труднее, и в конечном счёте его либо завернут с просьбой вливать по частям, либо вольют и так, без замечаний (если есть доверие к автору и подстраховка в виде CI и тестовой среды, например).
В масштабной системе, где много взаимодействующих компонентов, случаются трудноуловимые баги, которые даже воспроизвести непросто. И действительно, можно провести много дней, просто в попытках воспроизвести локально проблему, которая возникает только на "проде" в полнолуние по нечётным месяцам.
Поддерживаю, было бы неплохо, если такая функция будет встроенной в клиент. Тем более, что боты для распознавания уже существуют, например silero_audio_bot (сам пользуюсь)
Может быть, этот комментарий нужно читать как стихи Маяковского)
Всё-таки это не "субституты", а "комплименты" (или дополняющие). Первые заменяют друг (например чай и кофе), вторые - покупаются "в довесок", вместе.
< zanuda mode=off / >
Слишком категорично. Вот мой пример: прошлой весной всерьёз собрался уходить, но когда позвонил тимлиду увольняться, предложили контроффер +20% к текущей ЗП. С тех пор и тимлид тот ушёл, а я до сих пор на этом же месте, больше полутора лет (правда, последние пару месяцев странные вещи творятся по организационной части, так что подумываю таки об уходе).