Передача составных данных методом POST

В жизни любого программиста попадаются задачки, которые человека цепляют. Вот не нравится стандартный метод решения и все! А порой бывает, что стандартные решения не подходят по какой-то причине. Некоторые люди обходят такие задачи стороной, другие же любят решать их. Можно даже сказать сами их находят. Одна из таких задач отсылка файла или несколько файлов методом POST.

Некоторые наверное скажут, эта задача совсем не задача. Ведь есть замечательная библиотека CURL, которая довольно простая и решает эту задачу легко! Но не спешите. Да, CURL мощная библиотека, да она загружает файлы, но… Как Вы знаете у нее есть маленькая особенность — файл должен быть размещен на жестком диске!

Предлагаем вам перевод поста «Unit Testing is Overrated» от Alex Golub, чтобы подискутировать на тему юнит-тестов. Действительно ли они переоценены, как считает автор, или же являются отличным подспорьем в работе? Опрос — в конце поста

Результаты использования юнит-тестов: отчаяние, мучения, гнев

Важность тестирования в современной разработке ПО сложно переоценить. Для создания успешного продукта недостаточно выпустить его и сразу забыть, это долгий итеративный процесс. После изменения каждой строки кода программа должна сохранять свою функциональность, что подразумевает необходимость тщательного тестирования.

В процессе развития отрасли разработки ПО совершенствовались и методики тестирования. Они постепенно сдвигались в сторону автоматизации и повлияли на саму структуру ПО, порождая такие «мантры», как «разработка через тестирование» (test-driven development), делая упор на такие паттерны, как инверсия зависимостей (dependency inversion), и популяризируя построенные на их основе высокоуровневые архитектуры.

Сегодня автоматизированное тестирование настолько глубоко связано в нашем сознании с разработкой ПО, что одно сложно представить без другого. И поскольку оно, в конечном итоге, позволяет нам быстро создавать ПО, не жертвуя при этом его качеством, то трудно спорить о полезности тестирования.

Однако, несмотря на существование различных подходов, современные «best practices» в основном подталкивают разработчиков к использованию конкретно юнит-тестирования. Тесты, область контроля которых находится в пирамиде Майка Кона выше, или пишутся как часть более масштабного проекта (часто совершенно другими людьми), или полностью игнорируются.

Преимущество такого подхода часть поддерживается следующим аргументом: юнит-тесты обеспечивают в процессе разработки наибольшую полезность, потому что способны быстро отслеживать ошибки и помогают применять упрощающие модульность паттерны разработки.

В этой статье рассматривается создание достаточного простого автотеста. Статья будет полезна начинающим автоматизаторам.

Материал изложен максимально доступно, однако, будет значительно проще понять о чем здесь идет речь, если Вы будете иметь хотя бы минимальные представления о языке Java: классы, методы, etc.

Самый первый рабочий созвон в моей жизни вызвал сложные чувства. С одной стороны, это было довольно круто — я говорил с американцами из майкрософт как равный член команды, меня слушали, и это подняло мне самооценку. С другой стороны, у меня возникло странное ощущение — вот мы проговорили четыре часа, и по факту не узнали и не сказали ничего нового. Тупо потратили кучу времени.

Я подумал — ну окей, так, наверное, бывает не всегда. С тех пор прошло лет 5, я не раз менял работу, но везде и всегда созвоны были пустой тратой времени.

Пару лет назад друзья скинули очень забавный комикс под названием “Сова — эффективный менеджер”. Я посмеялась, подумала, что смешно, такого же не бывает, как классно утрированы ситуации. Но очень скоро этот комикс стал моей реальностью — в нашей команде появился он: “эффективный” менеджер, и стало не до смеха.

Итак, с этого момента начинается вызов для продакт/проджект менеджера и команды. В ходе этой истории все стороны понесли огромные потери: и инвестор, и продукт, и команда. Но главное, что из подобных ситуаций выход есть, а масштабы бедствия можно локализовать и сократить.

Собрал для вас цитаты из разных книг по важной, на мой взгляд, теме: что нужно для изменений – инструкция или принципы.

Несмотря на всю абсурдность идеи брать чей-нибудь готовый кейс и использовать его у себя, именно так и поступают менеджеры в большинстве случаев. Это вполне объяснимо: сделать по инструкции проще, чем брать какие-то принципы, кубики, и лепить из них собственный кейс, с учетом особенностей своей компании. А главное: за результат отвечать не надо. Если не сработало, то виноват кейс. Так появляются тысячи статей, постов, видео и выступлений о неэффективности повышения эффективности.

Цитаты я собрал не для менеджеров – они будут продолжать действовать по-своему. Рынок продуктов для «здорового образа жизни организаций» слишком велик и привлекателен, чтобы начинать думать головой.

Цитаты я собрал для нас – «глобусов», на которых «натягивают сову». Большинство книг, из которых взяты цитаты, входят в обязательный менеджерский набор. Так что можно крыть их же козырями.

Некоторые цитаты длинноваты — не хотел прерывать авторов, вырывать мысль из контекста.

Телеграмму накатал:

«Шлите денег — отбатрачу,
Я их все прохохотал».

_{/В.Высоцкий/}

Тот, кто впервые выходит на фондовый рынок как частный инвестор, сразу думает о двух активах: акциях и валюте. Эти инструменты кажутся простыми и прозрачными. Но если бы всё было так просто, эту статью писал бы долларовый миллионер для долларовых миллионеров. Акции — инструмент коварный и крайне непростой, он требует профессионального подхода и не прощает ошибок. Это уже далеко не те случаи, которые показывают в захватывающих фильмах про биржевиков XX века — это фондовый рынок 2020. Даже первый шаг должен быть очень серьёзным.

Источник

Аналитика рынка разработчиков и CTO:

• Сколько денег хотят разработчики и CTO, которые не ищут работу и как можно их замотивировать
• 4 ключевых причины, которые могут снижать стоимость разработчиков и что может повышать их ценность;
• 12 факторов, с помощью которых вы можете заинтересовать опытных экспертов;
• Могут ли кандидаты стоить для вас дешевле. Что делать, если у вас проблемы с наймом. Как кризис и пандемия повлияли на хантинг. Общие рекомендации современного хантинга.

Начальник заставляет работать по ночам или в выходные? Орёт при всех матом? Позволяет себе пошлые шутки? Коллеги постоянно и настоятельно требуют помощи? Премию так и не дают, а зарплату не повышают? Ваше возмущение вызывает, в лучшем случае, смех?

Это Догвилль, и вы стали его жертвой. Я сразу прошу прощения – не знаю, как это явление называется в психологии, поэтому использую название чудесного фильма, который наглядно и жутко проникновенно раскрывает его механику и последствия.

Этот подход в общении и, особенно, управлении используют примерно все, причём – бессознательно. Даже дети и животные. Поглядим, как он работает.

В прошлом году я участвовал в соревнованиях JS13K 2019, на которых людям предлагается разрабатывать игры в менее чем 13 КБ кода на JavaScript. Я участвовал с клоном Doom, который назвал… «Ещё один клон Doom» (Yet Another Doom Clone).


Поиграть в него можно здесь. Исходный код выложен сюда.

Зачем создавать клон Doom?

Зачем писать FPS на JavaScript всего в 13 КБ (с учётом сжатия)? По нескольким причинам. Но лучше всего на этот вопрос отвечает раздел FAQ соревнований JS13K «Можно ли использовать WebGL?»:

«Да, но может быть сложно уместить его в 13 килобайта, если вы планируете писать FPS».

Кроме того, в то время я как раз написал 3D-рендерер и хотел поработать над ним ещё. К тому же мне нравится создавать сильно сжатый код. (Например, много лет назад я создал язык и написал компилятор для нового языка, предназначенный специально для использования в код-гольфинге.)

Именно поэтому я выбрал FPS. Остаётся вопрос: «Почему Doom?» На него ответить проще: если вы хотите написать FPS, и чтобы он при этом был небольшим, то Doom — практически самый минималистичный вариант.

2,4 ГГц — это плохо. 5 ГГц — это хорошо. 6 ГГц — это ещё лучше, но послезавтра. Все это знают, кого я тут учу, в самом деле. Всё это хорошо, только делать-то что, когда ты такой, как умный, открываешь какой-нибудь Wi-Fi Explorer, а там сатанизм и этажерки, как на скриншоте?



Шаг первый — поплакать. Шаг второй — нырнуть под кат. Вопрос простой, а ответ — нет.

Привет, Хаброжители! Хотите повысить свою эффективность в разработке корпоративных и облачных Java-приложений?

Увеличьте скорость и простоту разработки микросервисов и сложных приложений, избавившись от забот по конфигурации Spring.

Используйте Spring Boot 2 и такие инструменты фреймворка Spring 5, как WebFlux, Security, Actuator, а также фреймворк Micrometer, предоставляющий новый способ сбора метрик.

Как и любой здоровый человек — могу назвать себя в меру ленивым.

Так, например, мне лень писать длинный pipeline (вообще писать руками pipeline лень). И мне не нравится идея гонять туда — сюда файлик, в который придётся писать параметры, для чего городить огород из лишнего кода.

Кстати, может кто-то из читателей этой статьи сможет объяснить, почему нужно выполнять все операции (сборка дистрибутива, его тестирование и т. д.) на той же машине, где расположен Jenkins? Я вот так не считаю и моя архитектура построена так, что Jenkins нужен для запуска задач, а вот они (задачи) выполняются на отведённых под эти вещи машинах. Но это лирика и желание пообщаться и поделиться опытом.

Сама статья о другом: как сохранить параметры и параметризовать регулярную Job'у удобно и штатно?

Давайте представим гипотетическую ситуацию, когда вам нужно сделать регулярный запуск некоторого набора тестов по расписанию.

Вы уже сделали некоторою Job'у, с использованием плагина Active Choices и теперь вы молодцы и можете запускать руками нужный набор.

Но как теперь объединить обе этих функции, чтобы получить выгоду от обоих подходов?
Не буду рассказывать всех тех вариантов, которые мне пришлось услышать или попробовать, а сразу перейду к самой сути. Решение моё лишь частично, так как реализация была найдена на Medium. Я же решил поделиться им с сообществом, чтобы больше людей перестали костылить и делать глупости.

Как-то раз, наткнувшись на схему развития областей знаний тимлида, подумала, что это прекрасный способ систематизации и для HR в IT. Теперь хочу поделиться тем, что у меня получилось со всеми, кто знает эту область компетенций пятнами и без особой систематизации:



На верхнем уровне у меня получилось 10 областей компетенций. Было бы неплохо, чтобы по каждой из них был выделенный HR. Но, как правило, это утопия. По факту HR-ы вынуждены заниматься всем и одновременно. В результате, эффект такой, как лучше бы вообще не брались.

Борьба со сложностью является постоянной темой в области создания программного обеспечения, которое я встречаю снова и снова. Это нечто, что я постоянно вижу в обсуждениях на всех уровнях, ну например, как много комментариев должно сопровождать методы и функции? Каково идеальное "количество" абстракции? Когда фреймворк начинает содержать "слишком много магии"? Когда в компании используется слишком много языков программирования?

Мы пытаемся избавиться от сложности, обуздать её и ищем простоты. Я думаю, что представлять себе суть вещей таким образом, — это ложный путь. Сложность обязательно должна где-то обитать.

В конце 2017 года мы создали Telegram-бота Headz analytics. Он мониторит зарплаты в IT-отрасли для самых популярных языков программирования в 12 крупнейших городах России. Бот выдает информацию как по вилке зарплат и ожиданиям работодателей, так и зарплатным ожиданиям соискателей из открытых источников: HeadHunter, Хабр Карьера, Telegram, а также нашей собственной базы.



За зиму 2019-2020 года мы собрали данные по спросу и предложению в IT и обработали. Что получилось: максимальная средняя зарплата в IT не в Москве, соотношение предложений резюме и вакансий иногда достигает 14 к 1, а в регионах встречаются специальности, для которых есть только одно предложение от работодателя на целый город. Остальные выводы из цифр — в статье с графиками и диаграммами.

Я пишу эту статью для своих бывших коллег и знакомых. Раз за разом по неопытности они попадают в одни и те же проблемы с непосредственным руководством. Но их ситуации далеко не уникальны, и эти советы могут помочь многим сделать свою жизнь лучше.

В чем отличается взгляд на карьеру у разработчика и его руководителя

Жизнь полна противоречий. Даже свет не может определиться, кто он – частица или волна.
В мире разработки софта противоречий между действующими лицами вагон и маленькая тележка. Давайте рассмотрим пару – разработчик и руководитель разработки (это может быть руководитель проекта, технический менеджер, тимлид). Как выяснится, эти двое зачастую по-разному смотрят на вещи и вообще стремятся в разные стороны.

Чего хочет разработчик

Все хотят разного. Но поскольку без обобщений нам не обойтись, возьмем сферического в вакууме разработчика уровня middle. Он в меру ленив, в меру любопытен и ему в целом нравится его профессия. Ему бы только сроки помягче, процессы получше, задачи поинтереснее.

Как он хочет развиваться? А вот так:

• Изучать новые технологии
• Решать более интересные задачи
• Участвовать в новых проектах
• Поменьше заниматься деятельностью, не связанной с разработкой
• Принимать решения самостоятельно

В то же время его руководитель хочет:

• Чтобы разработчик хорошо знал используемые технологии
• Чтобы разработчик хорошо справлялся с поставленными задачами: с должным качеством и в установленный срок
• Чтобы разработчик был ответственным и всегда завершал то, за что взялся
• Чтобы разработчик давал адекватные оценки задачам
• Чтобы разработчик имел понимание потребностей бизнеса и продукта в целом
• Чтобы разработчик своевременно сообщал о проблемах

Хотите знать, как добиться компромисса? Добро пожаловать под кат.

В прошлом видео мы говорили о том, что у команды должен быть мамонт — общая разделяемая цель, которую можно достичь только всем вместе. Но только цели — недостаточно, потому что после формирования команды в дело вступают социологические эффекты.

И тут нам на помощь пришел американский психолог Брюс Такман, которому довелось исследовать тысячи команд по заказу Министерства Обороны США. Военные пытались понять, как себя будут вести экипажи подводных лодок в автономном плавании. Не захочет ли кто уволиться? Или там предъявить капитану черную метку?

На основании этих исследований Такман сформулировал свой концепт, которым мы теперь с благодарностью пользуемся:



И тут необходимо вспомнить несколько историй из реальной жизни…

Когда Дудь выпустил ролик про долину, я очень сильно расстроился. Я ещё не знал, про что он конкретно, но мозг моментально нарисовал: манерные успешные успехи говорят про преодолевание, дух предпринимательства, поднятые миллионы баксов, и как сильно их говноприложенька влияет на мир.

Тогда я подумал — надо посмотреть, осудить и бахнуть статью. Про то, что Дудь засранец, а в настоящей разработке все по-другому. Прошло уже месяца два, но я так и не смог заставить себя это посмотреть.

Мои новостные ленты были завалены обсуждениями, восхищением и критикой выпуска. Каждый раз читая что-то об этом, я испытывал непонятную почти физическую боль. Ну хорошо, главный журналист страны рассказал про мою индустрию, но рассказал не так, как хочу я. С этим можно жить. Да, со всей своей преисполненностью и трушной технарскостью, я все ещё маленький завистливый чмошник. Я тоже хочу сидеть в кофейне в Пало-Альто и смотреть, как мне выписывают чек на пять миллионов долларов. Но смотрите, я вырос в России и давно научился не обращать внимания на свою патологическую зависть. Мне давно не бывает от нее больно.

Бомбанул я точно не от зависти — и я долго не знал, почему.