Для Perl есть десятки http-клиентов превосходного качества, а вы зачем-то команду curl зовёте. Понимаю, что код не Ваш, но я бы этот момент 100% просто сходу переписал (ну и, честно говоря, ещё и весь остальной код тоже).
А за статью спасибо!
>в котором абсолютно четко расписано как создается контейнер
В котором чётко прописано, что следует использовать внешнюю библиотеку такую-то версии от 2013-го года при том, что на официальном сайте давно лежит от 02.2019-го сборка и между той, что была в 2013 и той, что есть в 2019-м — десяток багфиксов, и среди них N-е количество security fix'ов.
Конечно, и security bug'ов добавилось с тех пор (как, возможно, и производительности насыпали, и каких-нибудь кривых зависимостей убрали), но атакующий-то о невыявленных пока ещё багах вряд ли что-то знает, поэтому будет рад софту, в котором куча дыр, описанных в security-бюллетенях за прошедшие 5 с лишним лет.
А почему такую замшелую библиотеку разработчики пихают в докер-контейнер? А потому что с ней — всё работает! Вот работало оно в 2013-м году, и в 2019-м работает. И, собственно, я не ошибусь, если скажу, что именно ради подобного (описание можете сами подставить по смыслу фразы) разработчики используют docker-контейнеры чаще всего. Они им нужны для того, чтобы с одной стороны таскать с собой целый ворох чужих библиотек, а с другой стороны — не дай Бог не подстраиваться к целевой системе. А то вдруг там библиотека не 2013-го года и скомпилированная, например, не со столь заботливо подобранными флагами, сакральные знания о которых передаются из поколение в поколение?
Безусловно, докер-контейнеры — это не про безопасность, и даже не про упаковку зависимостей, покрывающихся мхом и плесенью. Но большинство разработчиков используют докер не по назначению, а именно в качестве этакого грязного дырявого мешка, в который плотно набиваются все нужные костыли, чтобы при переносе на другую систему чудесное приложение не рассыпалось от ужасного столкновения с объективной реальностью, существующей где-то за рамками тестовых сред и разработческих макбуков.
В Crystal, компилируемом в нормальный машинный код языке, статическая типизация достигается просто и логично, при том. что синтаксис от python-то не сильно отличается (Ruby-like).
Но здесь — я как начал читать, у меня просто глаза на лоб полезли и волосы зашевелились. И это в интерпретируемом-то языке такая жесть.
Не далее, как пару дней назад ездил именно так, как это описала автор статьи. Ехал из Ижевска в Набережные Челны, водителя звали якобы Рустам, а оказался «как бы Михаил», автомобиль был вроде как обычный 4-х местный, а оказался VW Transporter. И т.д.
Соответственно, ехали 8 человек вместо четырёх, были постоянные лихие обгоны по встречке, в том числе и вслепую при заезде на подъём, когда там за подъёмом ничего не видно, в салоне играла какая-то дебиловатая музыка… Плохо ли это? Ну, если бы разбились — однозначно было бы плохо, а так всё-таки нужно учитывать следующие занятные факторы:
1) «Это Россия, детка!» А это значит, что никаких таких регулярных рейсовых маршрутов либо нет в принципе, либо автобус тащится со скоростью шоссейного велосипеда. В нашей стране не развит рынок, в том числе и рынок нормальных цивилизованных перевозок. Например, потому что наша страна является одной большой нефтегазозаправкой для других стран, где с рынком цивилизованных перевозок всё намного лучше;
2) Если бы не было маршруточников — то кто бы остался на блаблакаре? Получается, что там бы остались 5-10% людей, которым интересно ездить с попутчиками. А мне нужно в те же Челны нудно было ехать «прямо сейчас или максимум в течение 3-х часов». Убрали бы этого маршруточника-обманщика, и что бы мне оставалось? Официальное такси за 5000 рублей в одну сторону?
3) Ну и в конечном итоге давайте подумаем, а что у нас в России работает вот в соответствии с теми идеалистическими представлениями о том, как одни люди помогают другим за небольшую плату? Ну или продают что-то недорого друг другу? Авито — это на 90% теневая экономика, т.е. магазины, которые не платят налоги. Сервисы квартирного найма — на 99% оккупированы агентствами, взымающими за свои услуги полную стоимость первого месяца проживания.
Давайте положим руку на сердце и признаемся друг другу честно: в нашей стране люди не доверяют друг другу, не стремятся к социальному взаимодействию (но стремятся максимально изолироваться от него за высокими непрозрачными оградами и тройными замками), в нашей стране просто исчезающе мало людей с европейским мировоззрением. И это не спроста, это напрямую связано с тем, что наш человек, не только декларирующий, но и реально исповедующий на практике европейские паттерны поведения — подвергает себя не очень оправданным рискам, поскольку его окружают люди, это мировоззрение даже близко не разделяющие и придерживающиеся концепции «человек человеку — волк».
В общем, с моей точки зрения, текущее положение дел — не вина блаблакар, это вина нашего общества. А коллективная ответственность эквивалентна ответственности каждого. Вот мы и несём бремя этой ответственности в форме поездок на маршрутках вместо путешествий в хипстерском духе этакого автомобильного каучсёрфинга.
А в итоге где всё-таки подешевле можно купить биту с тактическим фонарём на XML-T6? Мне срочно нужно, мне завтра ехать в район Химмаш в Екатеринбурге!
P.S. Проблема с поиском "дешёвых" предложений через поисковик — ровно в том, что он выдаст не то, что дешевле, а то, за что ему больше заплатили. А уж о я/маркете даже речи не идёт: продавцы столько платят за размещение там, что дёшево у них уже не может быть по определению.
Я не представляю себе как можно стандартизировать логгирование
Речь не о техническом документе, хотя для того же кода на C бывает полезно делать trace-отладку типа «вошли в функцию такую-то, важный аргумент такой-то равен вот этому значению» и вокруг обработки внешнего ввода хорошо бы расставлять побольше диагностики, потому что это и есть реальный источник львиной доли ошибок в якобы хорошо протестированных приложениях. Речь скорее о некоем «кодексе чести», чётко сформулированных принципах вроде того, что «не коммитим код со сложной/нетривиальной логикой, не вставив человекочитаемые диагностические сообщения для логера».
Тем не менее проблема с async-io — вполне решаема, и это даже не высшая математика, как ни странно.
Может со мной что-то не так, но я никогда не испытывал проблем со стектрейсом
Я думаю, что с Вами всё так. Просто Вы — разработчик. А я — в большинстве случаев пользователь, пусть и довольно сложного софта. Когда я разрабатываю что-то — мне интересны стек-трейсы. Когда я как пользователь вижу стек-трейс на экране вместо вменяемой диагностики проблемы («Отсутствует файл такой-то, процедура установки выполнена некорректно», «Файл такой-то недоступен для записи, проверьте прав доступа», «Не могут создать новый сокет — проверьте лимиты на количество открытых файлов») — у меня это вызывает как минимум раздражение: я не понимаю, почему я должен видеть информацию, которая понятна только разработчику, если приложение мне дали как продуктивное, а не как некий «subject for deeper debugging». Во многих ситуациях я могу сам исправить проблему или даже искусственно создать приложению те условия, в которых оно всё-таки будет работать, даже если в нём и содержится какой-то баг. Мне-то нужно, чтобы оно работало, а не собирало стек-трейсами «полезную информацию для отладки продуктива».
По-моему при разработке софта, как и в общении с другими людьми, самый важный и просто критически недооценённый людьми с узко-технарским кругозором момент — это способность мысленно поставить себя на место того, кто будет пользоваться продуктом интеллектуальной деятельности разработчика (а при общении — способность мысленно поставить себя на место того, кто выслушивает твою очередную едкую праведно-гневную филипику).
Это не только важный момент, но ещё и объективно — самый сложный, потому что очень трудно отринуть весь свой опыт и все свои единственно верные представления об окружающем мире — и попытаться представить, как мыслит и чего, собственно, хочет тот человек, который будет пользоваться плодами твоей работы. А ему, как это ни странно, может быть важно совсем не то, что важно тебе: не экономия миллисекунд, а грамотно написанная документация, которая позволяет не влезать в исходные коды, чтобы понять «как же оно на самом деле работает», не тестирование, покрывающее искусственно смоделированные ситуации, а возможность оперативно решить проблему в случае возникновения ситуации, которая может вообще никак и никогда не моделироваться в искусственной среде.
Нужно понимать, что наличие реальных денег в компании зависит от заказчиков. И от наличия реальных денег в компании атмосфера в коллективе в российских реалиях зависит порой куда больше, нежели от того, предпочитают там hg или git. И хотя понятно, что с заказчиком взаимодействуют не сами разработчики напрямую — всё-таки не стоит забывать, для кого и для каких реальных условий эксплуатации пишется ваше ПО.
Я как человек с преимущественно админским опытом, успевший поработать с тысячами «единиц» разного софта, задал бы ещё несколько вопросов:
1) А что конкретно ваш софт пишет в логи? Есть ли в компании какие-то стандарты, не позволяющие разработчикам не логировать ничего или логировать на «отстань от меня, пожалуйста» или логировать только на этапе отладки, а затем просто на уровне макросов удалять все вызовы логера, «чтоб оно у клиента/заказчика быстрее работало и чтоб клиент не видел лишнего!» Насчёт макросов — вопрос не о конкретном ЯП, а просто принципиальном подходе. Есть такие вещи как OpenLDAP, Samba и Zabbix, умеющие логировать всё чуть ли не построчно, а есть — что-то вроде rsyslogd или zebra, которые могут быть весьма загадочны и непредсказуемы
2) Есть ли определённый стандарт подробности обработки исключений? Насколько распространена ситуация, когда исключение «обрабатывается» (снова по принципу «на… отцепись пожалуйста») на 5 уровней выше того места, где оно возникает? Отличаются ли информация, предоставляемая в случае возникновения исключения, для этапа «отладки» и этапа эксплуатации заказчиком в продуктиве. Есть ли понимание того, что заказчику может быть как минимум неприятно и больно видеть стек-трейс с глубиной вложенности в 20 уровней и что неплохо бы предоставлять в таких случаях информацию, полезную заказчику «что в общих чертах произошло и как это можно исправить», а не предполагать, что заказчик во всех абсолютно ситуациях должен бежать к вам, о великий разработчик, даже если недотестированное и вывалившее какую-то невразумительную околесицу приложение нужно здесь и сейчас. Я неоднократно сталкивался с приложениями, которые вываливали гигантский стек-трейс в ответ на что-то вроде «не могу забиндится на порт» или «такого файла не существует». Если честно, в таких случаях у меня абсолютно всегда возникало желание кастрировать тех, кто так пишет софт. Я сам не всегда пишу тесты и не всегда даже пользуюсь системами контроля версий, но зная о том, насколько критичными бывают вменяемые сообщения об ошибках — хотя бы никогда не делаю их криптографическими и понятными только мне как разработчику.
3) Ну и да, я бы обязательно узнал, почему в компании выбрали именно Python при таком обилии качественных и несложных компилируемых языков со статической типизацией. Потому что база данных — это, безусловно, хорошо (особенно когда это не MySQL vs PostgreSQL, а что-то вроде PostgreSQL vs. ClickHouse vs. Tarantool), но если код пишется на интерпретируемом языке с прекрасным во всех отношениях GIL — наверное, для этого есть очень веские основания? Хорошо бы всё-таки при этом главным основанием была не дешевизна и переизбыток на рынке python-девелоперов, что позволяет убегать на совещания, когда очередной умник начинает задавать слишком много вопросов…
P.S. И да, сложность стандартных алгоритмов (на 99% уже имеющих готовую общедоступную реализацию, в т.ч. в виде C++ блобов для Python) — это, конечно, важно, но для оптимизации производительности неплохо бы знать и некоторые internals целевой системы. Поэтому конечно следует поинтересоваться у потенциального работодателя, что он знает, например, о современной структуре виртуальной памяти в Linux. Ну и классический конечно вопрос: если при async-io один из «потоков исполнения» зависнет — как глубокоуважаемый работодатель проконтролирует это и завершит подвисший кусок кода, упорно не желающий никому добровольно-кооперативно передавать управление? Кстати, поспрашивать работодателя о флагах clone, о преимуществах и недостатках разделяемой памяти (shared memory), о стоимости переходов между разными кольцами защиты ОС — тоже совершенно не повредит…
Arima Communications — тайваньская фирма. Что бы там ни думал официальный Китай, Тайвань был, есть и скорее всего будет независимым государством со своей уникальной производственной базой. Хотя качество изделий из Тайваня сейчас действительно не отличается практически от китайского.
Язык Си создан в 70-е — и в нём нет никакого ООП.
Язык QuickBASIC (компилятор, не путать с интерпретатором QBASIC), созданный в середине 80-х, позволяет одной директивой заставить разработчика декларировать типы всех переменных, и там тоже нет ООП.
При этом современный статически типизированный язык Crystal, например, который по задумке тотально ООП, не только в коде самого компилятора очень часто процедурный, но и позволяет без проблем писать в процедурном стиле.
При этом z = x + y в большинстве статически типизированных языков запросто приводит к неверному результату, и упомянутый тут язык Java долгое время таскал внутри себя баг в алгоритме бинарного поиска, когда результатом m = (l + r)/2 было число намного меньше l. Ибо Int склонен переполняться (впрочем, как и float, там просто разрядности мантиссы становится недостаточно), а проверить это разработчикам компиляторов не досуг.
При этом многие интерпретаторы динамически изменяют разрядность переменной при переполнении.
Я, собственно, к тому, что в статически типизированных языках нет ничего «современного», они появились вообще-то раньше динамических, в статически типизированных языках совершенно не обязательно использовать ООП (и совершенно не факт, что в динамически типизированном языке можно не использовать ООП), ну и да, в конечном итоге мне совершенно непонятно, причём тут вообще проектирование классов и статическая типизация.
P.S. И да, если убрать колоссальный пласт «неправильного» кода без ООП на том же языке Си — боюсь, что автору не пришлось бы написать свой пост, ибо нечем и некуда.
Чтобы работать с React вам нужно освоить основы Webpack. Webpack позволит тестировать код, разбивать на модули, сжимать его для продакшена и т.д.
— у меня возникает только один вопрос: кто здесь? (переформулирую: «кто все эти люди?» или «куда я попал?»).
Зачем так много заголовков, да ещё столь странных? Почему такое количество текста выделено, для чего? Всё это попахивает каким-то лютым трешем в духе книг по маркетингу для домохозяек.
Я понимаю, что нам приходится читать подобное регулярно, потому что слишком большое количество авторов в ой же Америке «подсели» на подобный стиль изложения в духе «доклад-презентация на крутой конференции», но дело в том, что при переводе легко подобные вещи сгладить, а не выдать в гипертрофированном виде.
Если это что-то вроде краткого содержания — тем более логичнее наверное вовсе пересказать собственными словами…
В итоге для меня навязчивый вопрос «что это вообще было?» так и повис в смысловом вакууме. Не проникся, честно, хотя идея наверняка была хорошая.
Недавно на Хабре была очень душевная и понятная даже мне, человеку очень далёкому от фронтенда, статья о React для начинающих. Написана хорошим русским языком, содержательная.
Здесь же я вижу косноязычный (и содержащий глупые ошибки недоредактированного google-перевода типа "JavaScript скрипт") перевод первой главы какой-то книги, которую после такого перевода я лично не захотел бы читать и в оригинале. Зачем было так делать? Например, когда я переводил документацию для Privoxy, у меня получался текст, превышающий по объёму и качеству оригинал, дополненный к тому же курсивными уточнениями переводчика. Не повод хвалиться, но я хотя бы знаю, что старался.
Подобные же Вашему переводу вещи, как мне кажется, попахивают халтурой и уж точно не делают React более популярным.
Коль скоро первый блин всё равно живёт в песочнице, мне кажется, ещё не поздно перевести дополнительные, более содержательные главы книги, поработав над качеством русского языка.
Прошу извинить меня за резкость, я не со зла, а в надежде на то, что хороших статей о Реакте будет больше.
Дочитал до «Ведь, вроде бы, работадателям выгодно держать», поперхнулся.
Я не граммар-наци, но как может сотрудник Crossover писать «работАдателям»? Они же не производством деревянной мебели занимаются, а наймом!
А что же делать, если в контейнеры распиханы самые разные версии одной и той же сторонней или даже своей библиотеки и вдруг выясняется, что в её версии такой-то выявлен жёсткий баг, а в контейнерах у нас, между тем, почти все версии — ниже «такой-то». Такой библиотекой может быть не только что-то банальное, но и libssl, а багом может быть и потенциальное переполнение буфера / получение shell или просто «фишка», позволяющая вашим конкурентам убить работающее приложение наповал.
ОСи на виртуалках обновляют компоненты одновременно, в них системные администраторы контролируют актуальность библиотек, своевременное залатывание security-hole'ов. Ааа… кто отвечает за это в случае, когда ключевые компоненты и библиотеки попросту суются внутрь контейнеров?
P.S> Нужно ещё отметить упор на «разные версии» одной библиотеки — это важно, потому что да, есть подход, позволяющий пресобрать все контейнеры, содержащие внутри библиотеку X, одним махом, после чего перезапустить контейнеры. Например, разделение контейнеризации на «слои» легко позволяет так делать. Но… «А что если приложению YZ нужна версия библиотеки XX0, а приложению TP нужна версия библиотеки XX1?» И тут конечно на стоит вопрос о том, чтобы исправить приложение, ринципиально использующее древнюю и бажную как Г мамонта версию библиотеки. Точно так же, как и про то, что контейнеры должны бы собираться послойно разработчики знать не хотят. Я прав?
По-моему как раз с «начальственностью» у разного рода варягов нет проблем: они считают себя исполнительным механизмом, работающим по какому-то «платиновому» алгоритму, описанному в толстых учебниках. В действительности и среди разработчиков полно тех, кто пишет код, руководствуясь не условиями задачи и реальными сроками, а некими околорелигиозными представлениями о «лучших практиках». При этом разработчик боится быть непонятым и неооцененным гипотетическими виртуальными коллегами, которые когда нибудь «будут править его код», но не боится не выполнить работу в срок или выполнить не все требования заказчика или выполнить их неверно, скорректировав по пути удобным для себя образом. Точно так же и менеджеры, руководствующиеся в своей деятельности формальными алгоритмами очень часто не видят вообще компанию как таковую, а видят только соответствие или несоответствие неких показателей, действуя словно по универсальной инструкции для настройки уникального механизма. Точно так же и у велосипедного мастера, который будет настраивать по стандартным инструкциям производителей далеко не новый велосипед, претерпевший за время эксплуатации множество изменений — результаты будут в лучшем случае очень средними, но скорее всего — они будут ниже среднего.
Но относительно спорности того момента, что руководитель разработчиков обязан сам быть разработчиком лучше тех, кем руководит — полностью согласен. У менеджера своя сфера деятельности, и я не думаю, что сами разработчики будут рады, если управленец будет на полном серьёзе пытаться постоянно контролировать и выносить какие-то суждения относительно internals разработки программного продукта, при этом являясь даже не тимлидом группы, а начальником отдела, например.
>Если прибыль выросла, продажи растут, издержки снижаются — это эффективный менеджер.
Эффективный менеджер — это тот, кто умеет видеть не только абсолютные значения, но и первую, вторую производные как минимум. Если прибыли растут, а эффективный потенциал компании снижается — это значит, что при другом сценарии (например, не уволили якобы неэффективных высокооплачиваемых профессионалов из компании и не наняли быстро набивающих произвольный текст мартышек) — компания могла бы достигнуть в 10 раз большей прибыли, но не сейчас, а через 2 года. А при выбранном нанятым варягом сценарии «прибыль здесь и сейчас» — через 2 года компания уже уйдёт в глубокий минус и прекратит своё бездарное существование.
Менеджмент — это прежде всего управление ресурсами компании, и сотрудники — это тоже ресурс, только на порядки более сложный, нежели серверы в стойках или купленное ПО. И если менеджер не умеет и не желает понимать собственно людей, которые и есть та самая производящая сила компании — то он никак не может быть эффективным. А управление людьми на основании попугайских баллов с полной самоизоляцией от якобы легко взаимозаменяемых «чёрных рабов» в стенах комфортабельных кабинетов — это как раз и есть классический подход тех управленцев, о которых пишет автор статьи.
Первый комментарий по существу. Браво!
Все (java-кодеры, если быть более точным) так увлеклись сравнением Java и Ruby, что никто по-моему так саму статью и не прочитал, несмотря на всю её исключительную лаконичность. А она и правда вытащена из какого-то пыльного чулана и весьма бессодержательна, к сожалению.
По теме: бездарный код можно писать на любом ЯП, точно так же как и прекрасный код можно писать на любом. Причём здесь трансформации данных? Вы настолько глупы, что на полном серьёзе считаете, что на Ruby пишут приложения, не приходя в сознание, а на Java — только что-то мега-вдумчивое? Я даже оспаривать это не буду, потому что это не точка зрения, это — маразм.
Относительно «ошибки»: извините, но если Вы — грамотный человек, то Вы не напишете слово «инцидент» через «е» — как минимум потому что неоднократно встретите его в книгах, периодических изданиях, письмах коллег. Если же Вы — безграмотный человек, не ведающий о существовании правил орфографии и пунктуации, то с какой стати Ваш маразм должен быть кому-то интересен?
Для Perl есть десятки http-клиентов превосходного качества, а вы зачем-то команду curl зовёте. Понимаю, что код не Ваш, но я бы этот момент 100% просто сходу переписал (ну и, честно говоря, ещё и весь остальной код тоже).
А за статью спасибо!
В котором чётко прописано, что следует использовать внешнюю библиотеку такую-то версии от 2013-го года при том, что на официальном сайте давно лежит от 02.2019-го сборка и между той, что была в 2013 и той, что есть в 2019-м — десяток багфиксов, и среди них N-е количество security fix'ов.
Конечно, и security bug'ов добавилось с тех пор (как, возможно, и производительности насыпали, и каких-нибудь кривых зависимостей убрали), но атакующий-то о невыявленных пока ещё багах вряд ли что-то знает, поэтому будет рад софту, в котором куча дыр, описанных в security-бюллетенях за прошедшие 5 с лишним лет.
А почему такую замшелую библиотеку разработчики пихают в докер-контейнер? А потому что с ней — всё работает! Вот работало оно в 2013-м году, и в 2019-м работает. И, собственно, я не ошибусь, если скажу, что именно ради подобного (описание можете сами подставить по смыслу фразы) разработчики используют docker-контейнеры чаще всего. Они им нужны для того, чтобы с одной стороны таскать с собой целый ворох чужих библиотек, а с другой стороны — не дай Бог не подстраиваться к целевой системе. А то вдруг там библиотека не 2013-го года и скомпилированная, например, не со столь заботливо подобранными флагами, сакральные знания о которых передаются из поколение в поколение?
Безусловно, докер-контейнеры — это не про безопасность, и даже не про упаковку зависимостей, покрывающихся мхом и плесенью. Но большинство разработчиков используют докер не по назначению, а именно в качестве этакого грязного дырявого мешка, в который плотно набиваются все нужные костыли, чтобы при переносе на другую систему чудесное приложение не рассыпалось от ужасного столкновения с объективной реальностью, существующей где-то за рамками тестовых сред и разработческих макбуков.
Но здесь — я как начал читать, у меня просто глаза на лоб полезли и волосы зашевелились. И это в интерпретируемом-то языке такая жесть.
Соответственно, ехали 8 человек вместо четырёх, были постоянные лихие обгоны по встречке, в том числе и вслепую при заезде на подъём, когда там за подъёмом ничего не видно, в салоне играла какая-то дебиловатая музыка… Плохо ли это? Ну, если бы разбились — однозначно было бы плохо, а так всё-таки нужно учитывать следующие занятные факторы:
1) «Это Россия, детка!» А это значит, что никаких таких регулярных рейсовых маршрутов либо нет в принципе, либо автобус тащится со скоростью шоссейного велосипеда. В нашей стране не развит рынок, в том числе и рынок нормальных цивилизованных перевозок. Например, потому что наша страна является одной большой нефтегазозаправкой для других стран, где с рынком цивилизованных перевозок всё намного лучше;
2) Если бы не было маршруточников — то кто бы остался на блаблакаре? Получается, что там бы остались 5-10% людей, которым интересно ездить с попутчиками. А мне нужно в те же Челны нудно было ехать «прямо сейчас или максимум в течение 3-х часов». Убрали бы этого маршруточника-обманщика, и что бы мне оставалось? Официальное такси за 5000 рублей в одну сторону?
3) Ну и в конечном итоге давайте подумаем, а что у нас в России работает вот в соответствии с теми идеалистическими представлениями о том, как одни люди помогают другим за небольшую плату? Ну или продают что-то недорого друг другу? Авито — это на 90% теневая экономика, т.е. магазины, которые не платят налоги. Сервисы квартирного найма — на 99% оккупированы агентствами, взымающими за свои услуги полную стоимость первого месяца проживания.
Давайте положим руку на сердце и признаемся друг другу честно: в нашей стране люди не доверяют друг другу, не стремятся к социальному взаимодействию (но стремятся максимально изолироваться от него за высокими непрозрачными оградами и тройными замками), в нашей стране просто исчезающе мало людей с европейским мировоззрением. И это не спроста, это напрямую связано с тем, что наш человек, не только декларирующий, но и реально исповедующий на практике европейские паттерны поведения — подвергает себя не очень оправданным рискам, поскольку его окружают люди, это мировоззрение даже близко не разделяющие и придерживающиеся концепции «человек человеку — волк».
В общем, с моей точки зрения, текущее положение дел — не вина блаблакар, это вина нашего общества. А коллективная ответственность эквивалентна ответственности каждого. Вот мы и несём бремя этой ответственности в форме поездок на маршрутках вместо путешествий в хипстерском духе этакого автомобильного каучсёрфинга.
А в итоге где всё-таки подешевле можно купить биту с тактическим фонарём на XML-T6? Мне срочно нужно, мне завтра ехать в район Химмаш в Екатеринбурге!
P.S. Проблема с поиском "дешёвых" предложений через поисковик — ровно в том, что он выдаст не то, что дешевле, а то, за что ему больше заплатили. А уж о я/маркете даже речи не идёт: продавцы столько платят за размещение там, что дёшево у них уже не может быть по определению.
Речь не о техническом документе, хотя для того же кода на C бывает полезно делать trace-отладку типа «вошли в функцию такую-то, важный аргумент такой-то равен вот этому значению» и вокруг обработки внешнего ввода хорошо бы расставлять побольше диагностики, потому что это и есть реальный источник львиной доли ошибок в якобы хорошо протестированных приложениях. Речь скорее о некоем «кодексе чести», чётко сформулированных принципах вроде того, что «не коммитим код со сложной/нетривиальной логикой, не вставив человекочитаемые диагностические сообщения для логера».
Я думаю, что с Вами всё так. Просто Вы — разработчик. А я — в большинстве случаев пользователь, пусть и довольно сложного софта. Когда я разрабатываю что-то — мне интересны стек-трейсы. Когда я как пользователь вижу стек-трейс на экране вместо вменяемой диагностики проблемы («Отсутствует файл такой-то, процедура установки выполнена некорректно», «Файл такой-то недоступен для записи, проверьте прав доступа», «Не могут создать новый сокет — проверьте лимиты на количество открытых файлов») — у меня это вызывает как минимум раздражение: я не понимаю, почему я должен видеть информацию, которая понятна только разработчику, если приложение мне дали как продуктивное, а не как некий «subject for deeper debugging». Во многих ситуациях я могу сам исправить проблему или даже искусственно создать приложению те условия, в которых оно всё-таки будет работать, даже если в нём и содержится какой-то баг. Мне-то нужно, чтобы оно работало, а не собирало стек-трейсами «полезную информацию для отладки продуктива».
Это не только важный момент, но ещё и объективно — самый сложный, потому что очень трудно отринуть весь свой опыт и все свои единственно верные представления об окружающем мире — и попытаться представить, как мыслит и чего, собственно, хочет тот человек, который будет пользоваться плодами твоей работы. А ему, как это ни странно, может быть важно совсем не то, что важно тебе: не экономия миллисекунд, а грамотно написанная документация, которая позволяет не влезать в исходные коды, чтобы понять «как же оно на самом деле работает», не тестирование, покрывающее искусственно смоделированные ситуации, а возможность оперативно решить проблему в случае возникновения ситуации, которая может вообще никак и никогда не моделироваться в искусственной среде.
Нужно понимать, что наличие реальных денег в компании зависит от заказчиков. И от наличия реальных денег в компании атмосфера в коллективе в российских реалиях зависит порой куда больше, нежели от того, предпочитают там hg или git. И хотя понятно, что с заказчиком взаимодействуют не сами разработчики напрямую — всё-таки не стоит забывать, для кого и для каких реальных условий эксплуатации пишется ваше ПО.
1) А что конкретно ваш софт пишет в логи? Есть ли в компании какие-то стандарты, не позволяющие разработчикам не логировать ничего или логировать на «отстань от меня, пожалуйста» или логировать только на этапе отладки, а затем просто на уровне макросов удалять все вызовы логера, «чтоб оно у клиента/заказчика быстрее работало и чтоб клиент не видел лишнего!» Насчёт макросов — вопрос не о конкретном ЯП, а просто принципиальном подходе. Есть такие вещи как OpenLDAP, Samba и Zabbix, умеющие логировать всё чуть ли не построчно, а есть — что-то вроде rsyslogd или zebra, которые могут быть весьма загадочны и непредсказуемы
2) Есть ли определённый стандарт подробности обработки исключений? Насколько распространена ситуация, когда исключение «обрабатывается» (снова по принципу «на… отцепись пожалуйста») на 5 уровней выше того места, где оно возникает? Отличаются ли информация, предоставляемая в случае возникновения исключения, для этапа «отладки» и этапа эксплуатации заказчиком в продуктиве. Есть ли понимание того, что заказчику может быть как минимум неприятно и больно видеть стек-трейс с глубиной вложенности в 20 уровней и что неплохо бы предоставлять в таких случаях информацию, полезную заказчику «что в общих чертах произошло и как это можно исправить», а не предполагать, что заказчик во всех абсолютно ситуациях должен бежать к вам, о великий разработчик, даже если недотестированное и вывалившее какую-то невразумительную околесицу приложение нужно здесь и сейчас. Я неоднократно сталкивался с приложениями, которые вываливали гигантский стек-трейс в ответ на что-то вроде «не могу забиндится на порт» или «такого файла не существует». Если честно, в таких случаях у меня абсолютно всегда возникало желание кастрировать тех, кто так пишет софт. Я сам не всегда пишу тесты и не всегда даже пользуюсь системами контроля версий, но зная о том, насколько критичными бывают вменяемые сообщения об ошибках — хотя бы никогда не делаю их криптографическими и понятными только мне как разработчику.
3) Ну и да, я бы обязательно узнал, почему в компании выбрали именно Python при таком обилии качественных и несложных компилируемых языков со статической типизацией. Потому что база данных — это, безусловно, хорошо (особенно когда это не MySQL vs PostgreSQL, а что-то вроде PostgreSQL vs. ClickHouse vs. Tarantool), но если код пишется на интерпретируемом языке с прекрасным во всех отношениях GIL — наверное, для этого есть очень веские основания? Хорошо бы всё-таки при этом главным основанием была не дешевизна и переизбыток на рынке python-девелоперов, что позволяет убегать на совещания, когда очередной умник начинает задавать слишком много вопросов…
P.S. И да, сложность стандартных алгоритмов (на 99% уже имеющих готовую общедоступную реализацию, в т.ч. в виде C++ блобов для Python) — это, конечно, важно, но для оптимизации производительности неплохо бы знать и некоторые internals целевой системы. Поэтому конечно следует поинтересоваться у потенциального работодателя, что он знает, например, о современной структуре виртуальной памяти в Linux. Ну и классический конечно вопрос: если при async-io один из «потоков исполнения» зависнет — как глубокоуважаемый работодатель проконтролирует это и завершит подвисший кусок кода, упорно не желающий никому добровольно-кооперативно передавать управление? Кстати, поспрашивать работодателя о флагах clone, о преимуществах и недостатках разделяемой памяти (shared memory), о стоимости переходов между разными кольцами защиты ОС — тоже совершенно не повредит…
Язык QuickBASIC (компилятор, не путать с интерпретатором QBASIC), созданный в середине 80-х, позволяет одной директивой заставить разработчика декларировать типы всех переменных, и там тоже нет ООП.
При этом современный статически типизированный язык Crystal, например, который по задумке тотально ООП, не только в коде самого компилятора очень часто процедурный, но и позволяет без проблем писать в процедурном стиле.
При этом z = x + y в большинстве статически типизированных языков запросто приводит к неверному результату, и упомянутый тут язык Java долгое время таскал внутри себя баг в алгоритме бинарного поиска, когда результатом m = (l + r)/2 было число намного меньше l. Ибо Int склонен переполняться (впрочем, как и float, там просто разрядности мантиссы становится недостаточно), а проверить это разработчикам компиляторов не досуг.
При этом многие интерпретаторы динамически изменяют разрядность переменной при переполнении.
Я, собственно, к тому, что в статически типизированных языках нет ничего «современного», они появились вообще-то раньше динамических, в статически типизированных языках совершенно не обязательно использовать ООП (и совершенно не факт, что в динамически типизированном языке можно не использовать ООП), ну и да, в конечном итоге мне совершенно непонятно, причём тут вообще проектирование классов и статическая типизация.
P.S. И да, если убрать колоссальный пласт «неправильного» кода без ООП на том же языке Си — боюсь, что автору не пришлось бы написать свой пост, ибо нечем и некуда.
— у меня возникает только один вопрос: кто здесь? (переформулирую: «кто все эти люди?» или «куда я попал?»).
Зачем так много заголовков, да ещё столь странных? Почему такое количество текста выделено, для чего? Всё это попахивает каким-то лютым трешем в духе книг по маркетингу для домохозяек.
Я понимаю, что нам приходится читать подобное регулярно, потому что слишком большое количество авторов в ой же Америке «подсели» на подобный стиль изложения в духе «доклад-презентация на крутой конференции», но дело в том, что при переводе легко подобные вещи сгладить, а не выдать в гипертрофированном виде.
Если это что-то вроде краткого содержания — тем более логичнее наверное вовсе пересказать собственными словами…
В итоге для меня навязчивый вопрос «что это вообще было?» так и повис в смысловом вакууме. Не проникся, честно, хотя идея наверняка была хорошая.
Недавно на Хабре была очень душевная и понятная даже мне, человеку очень далёкому от фронтенда, статья о React для начинающих. Написана хорошим русским языком, содержательная.
Здесь же я вижу косноязычный (и содержащий глупые ошибки недоредактированного google-перевода типа "JavaScript скрипт") перевод первой главы какой-то книги, которую после такого перевода я лично не захотел бы читать и в оригинале. Зачем было так делать? Например, когда я переводил документацию для Privoxy, у меня получался текст, превышающий по объёму и качеству оригинал, дополненный к тому же курсивными уточнениями переводчика. Не повод хвалиться, но я хотя бы знаю, что старался.
Подобные же Вашему переводу вещи, как мне кажется, попахивают халтурой и уж точно не делают React более популярным.
Коль скоро первый блин всё равно живёт в песочнице, мне кажется, ещё не поздно перевести дополнительные, более содержательные главы книги, поработав над качеством русского языка.
Прошу извинить меня за резкость, я не со зла, а в надежде на то, что хороших статей о Реакте будет больше.
Я не граммар-наци, но как может сотрудник Crossover писать «работАдателям»? Они же не производством деревянной мебели занимаются, а наймом!
ОСи на виртуалках обновляют компоненты одновременно, в них системные администраторы контролируют актуальность библиотек, своевременное залатывание security-hole'ов. Ааа… кто отвечает за это в случае, когда ключевые компоненты и библиотеки попросту суются внутрь контейнеров?
P.S> Нужно ещё отметить упор на «разные версии» одной библиотеки — это важно, потому что да, есть подход, позволяющий пресобрать все контейнеры, содержащие внутри библиотеку X, одним махом, после чего перезапустить контейнеры. Например, разделение контейнеризации на «слои» легко позволяет так делать. Но… «А что если приложению YZ нужна версия библиотеки XX0, а приложению TP нужна версия библиотеки XX1?» И тут конечно на стоит вопрос о том, чтобы исправить приложение, ринципиально использующее древнюю и бажную как Г мамонта версию библиотеки. Точно так же, как и про то, что контейнеры должны бы собираться послойно разработчики знать не хотят. Я прав?
Но относительно спорности того момента, что руководитель разработчиков обязан сам быть разработчиком лучше тех, кем руководит — полностью согласен. У менеджера своя сфера деятельности, и я не думаю, что сами разработчики будут рады, если управленец будет на полном серьёзе пытаться постоянно контролировать и выносить какие-то суждения относительно internals разработки программного продукта, при этом являясь даже не тимлидом группы, а начальником отдела, например.
Эффективный менеджер — это тот, кто умеет видеть не только абсолютные значения, но и первую, вторую производные как минимум. Если прибыли растут, а эффективный потенциал компании снижается — это значит, что при другом сценарии (например, не уволили якобы неэффективных высокооплачиваемых профессионалов из компании и не наняли быстро набивающих произвольный текст мартышек) — компания могла бы достигнуть в 10 раз большей прибыли, но не сейчас, а через 2 года. А при выбранном нанятым варягом сценарии «прибыль здесь и сейчас» — через 2 года компания уже уйдёт в глубокий минус и прекратит своё бездарное существование.
Менеджмент — это прежде всего управление ресурсами компании, и сотрудники — это тоже ресурс, только на порядки более сложный, нежели серверы в стойках или купленное ПО. И если менеджер не умеет и не желает понимать собственно людей, которые и есть та самая производящая сила компании — то он никак не может быть эффективным. А управление людьми на основании попугайских баллов с полной самоизоляцией от якобы легко взаимозаменяемых «чёрных рабов» в стенах комфортабельных кабинетов — это как раз и есть классический подход тех управленцев, о которых пишет автор статьи.
Все (java-кодеры, если быть более точным) так увлеклись сравнением Java и Ruby, что никто по-моему так саму статью и не прочитал, несмотря на всю её исключительную лаконичность. А она и правда вытащена из какого-то пыльного чулана и весьма бессодержательна, к сожалению.
Относительно «ошибки»: извините, но если Вы — грамотный человек, то Вы не напишете слово «инцидент» через «е» — как минимум потому что неоднократно встретите его в книгах, периодических изданиях, письмах коллег. Если же Вы — безграмотный человек, не ведающий о существовании правил орфографии и пунктуации, то с какой стати Ваш маразм должен быть кому-то интересен?