0 просмотренных постов скрыто
Ответ на пост «Эффект Рингельмана»4
Для затравки вопрос к товарищам программистам - теоретически возможно разбить процесс на подпроцессы? Один пишет основную ветку, так сказать "тело" кода", другой - библиотеки, третий вычитывает...
Не, без шуток - только за последние сто лет (не будем трогать труд одиночек и перейдём сразу к заводам) производительность ручного труда выросла в разы. Даже без учёта автоматизации. Просто есть разница между эффективным менеджером, который отвёртку считает напитком, и производственником, который знает слабые места у себя в цеху. Лично учился у такого в кузне. Он один делал то, что мы втроём (!) делали в разы медленнее. Просто смекалка. Так и везде - если ты лично заинтересован в увеличении своей производительности, ты её увеличишь, что в офисе, что на производстве.
Подвиг Стаханова сейчас многие стебут, мол, на него пол-бригалы работало - одни вагонетки грузят, другие их вывозят и т.д. только вот целью было не показать, как у нас рабочий охуенно ебашит, а заявить, что при должной логистике добычу можно увеличить. И это мы ещё курилок и кофебрейков не касались.
И да, курицу можно приготовить быстрее, если её предварительно замариновать 😜
Ответ на пост «Эффект Рингельмана»4
О, мне есть что сказать
Во-первых, конечно, если менеджер не понимает, что добавление разработчика не всегда сокращает сроки, но всегда увеличивает трудозатраты - это так себе менеджер. Ну просто у него нет соответствующего опыта и квалификации. Может, он раньше строительными работами или копанием грядок занимался, и там это работало. Т.е. его опыт, если он и есть, нерелевантен.
Во-вторых, у меня реально были регулярные кейсы, когда работу делало пять разработчиков год, а по документам 5х12 сколько там будет? 60 разработчиков делало месяц. А все потому, что заказчик (госзаказчик) подписывает договор на работы за месяц до сдачи, и по договору у тебя N человекочасов. И ты должен расписать, как ты их потратил. Ты их тратил год, но за месяц до сдачи ты просто берешь всех разрабов в компании, вписываешь в договор и ходишь по офису, собираешь подписи. И по документам так и выходит, что девять женщин родят одного ребенка за месяц) Специфика аутсорса на госзаказчика))
Ответ на пост «Эффект Рингельмана»4
Девять женщин не родят ребенка за один месяц, и поэтому нету смысла добавлять двух разработчиков? Хорошо, добавим двух менеджеров.
Эффект Рингельмана4
Показать полностью
1
HTTP: для чего нужен - простыми словами
В прошлом посте я писала про REST API и приводила пример с рестораном — официант, кухня и меню. Теперь логично разобрать, как именно мы делаем заказ. Если API — это официант, который знает, что можно заказать, то HTTP — это правила, по которым мы должны этот заказ озвучить.
Допустим, мы посмотрели меню и нам нужно правильно сформулировать заказ. В ресторане есть правило: общаться вежливо и говорить подробно. Это и есть протокол передачи данных — HTTP/HTTPS. Соблюдая протокол, нужно сказать так: «Принесите, пожалуйста, говяжий стейк средней прожарки». Так официант нас точно поймет: мы вежливы и знаем, чего хотим. Если бы мы сказали просто «Мне стейк», то в лучшем случае получили бы стейк, но не говяжий. В худшем случае официант ничего не принесет.
HTTPS — это тот же HTTP, но с шифрованием, чтобы никто не подслушал наш заказ. По HTTP же данные передаются открыто, и сейчас почти все ресурсы используют HTTPS.
На этом можно было бы и закончить: ведь что такое HTTP я уже написала)
Далее опишу, как смотреть коды ошибок и зачем они нужны - что для проджекта может быть важно.
Когда мы вводим адрес сайта в браузере, происходит примерно вот что:
HTTP-запрос отправляется на сервер, сервер его понимает, выполняет нужные действия и возвращает HTTP-ответ.
Важно: запрос можно отправлять не только через браузер, есть множество других способов (инструменты разработчика, через командную строку — curl-запрос, и т.д).
Как выглядит HTTP-запрос?
Запрос всегда включает в себя:
Метод — что мы хотим сделать. Те самые GET, POST, PUT, PATCH, DELETE из предыдущего поста - часть HTTP запроса.
URL — куда отправляем запрос. Например /menu/steaks— посмотреть стйнки в меню.
Версию протокола — указываем, какую версию протокола использовать. Например, HTTP/1.1 или HTTP/2.
Заголовки (Request headers) — дополнительные данные. Например: с какого браузера мы передаем запрос? User-Agent: Mozilla/5.0.
Тело запроса (Body) — содержимое запроса. В GET-запросах тело отсутствует (хотя технически его передать можно), а в POST и PUT оно требуется для передачи данных.
Если кажется что сайт не работает, форма обратной связи не отправляется, если кажется что проблема не на вашей стороне: стоит проверить, возможно вам не кажется. Для этого можно посмотреть, что ответил нам сервер по HTTP-протоколу.
Самый простой способ посмотреть ответ - открыть DevTools: в браузре нажать F12 → перейти во вкладку Network → там прописаны все данные, из которых состоит запрос и ответ.
Что мы там увидим? Нас интересует вкладка Response - ответ сервера.
Сервер отвечает тоже по правилам:
Статус (код ответа) — получилось или нет. Например, 200 OK — всё хорошо, заказ точно такой, как и просили.
Коды делятся на группы:
1xx — «Ожидайте». Например, запрос принят, но заказ еще готовят.
2xx — «Всё хорошо». 200 OK: Вот ваш стейк.
3xx — «Редирект». К примеру 301: ресурс переехал. Куда? Нужно смотреть в заголовке, в поле Location.
4xx — «Ошибка клиента» (Мы ошиблись!). 400 Bad Request: тот случай, когда мы сказали «Мне стейк» и официант не понял, что мы хотим.
5xx — «Ошибка сервера» (Не мы ошиблись!). 500 Internal Server Error: отключили свет, и заказ приготовить сейчас не могут, но всё обязательно починят.
Заголовки (Response headers) — дополнительные данные, например: Content-Type: text/html говорит о том, что в теле ответа мы получили HTML-разметку.
Тело ответа — сами данные. В ресторане бы нам просто отдали сам стейк.
Но! Если сайт не работает, не всегда можно увидеть ответ. Сайт может просто не достучаться до сервера и на это могут быть разные причины - плохая настройка сервера, недоступность сети и другие, но не об этом сейчас)
Получилось очень объемно, и многое осталось без внимания, но своими постами я хочу не научить, а объяснить — всё-таки это разные вещи 🙂
Я начала вести тг канал, где рассказываю просто о сложном в IT.
Если вы дочитали этот пост, то скорее всего вас интересует тема, поэтому буду рада, если поддержите подпиской: https://t.me/jer_it
Показать полностью
API: объясняю как можно проще
Постараюсь объяснить проще на примере ресторана (это оказалось сложнее, чем с Agile, хотя казалось бы...)
API (Application Programming Interface) – интерфейс общения между программами. Это как "меню" или "набор правил", который позволяет разным программам общаться между собой.
Представим, что я пришла в ресторан: сажусь за столик, и ко мне подходит официант с меню. В этом меню — чёткий список блюд, которые я могу заказать. Я выбираю стейк средней прожарки с картофелем фри и передаю заказ официанту.
Что происходит дальше? Я не вижу, как повар готовит мой стейк, не знаю, где он берёт мясо и как его маринует. Мне важно только, чтобы официант принёс мне мой заказ как можно скорее. Если я передумаю и захочу изменить прожарку на medium rare или убрать гарнир — официант передаст эту просьбу на кухню, и мне принесут обновлённый заказ.
Я не вмешиваюсь в работу кухни и не говорю, как ему готовить — повар сам знает, что делать.
Точно так же происходит запрос через API: когда одна программа хочет взаимодействовать с другой, она не лезет во внутренние процессы, а просто делает "заказ".
Получается, что:
Официант - это API. Он принимает заказ и возвращает его с кухни.
Меню - это документация и правила API. В документации API прописаны все возможные варианты, которые API может вернуть, и дополнительные параметры.
Кухня - сервер, который обрабатывает наш запрос и возвращает ответ через API. Он сам знает, что нужно сделать, чтобы ответить нам; нам нужно только принять информацию и обработать её.
Самый распространённый вид API — REST API.
Он работает через HTTP-запросы (про HTTP то я и напишу в следующий раз).
Например, в ресторане мы можем не только заказать еду, но и попросить изменить или отменить заказ. В REST API тоже есть разные запросы:
GET — посмотреть меню: "Какие у вас есть стейки?"
В цифровом мире: получение списка товаров, статей или любой другой информации
POST — сделать новый заказ: "Я буду стейк medium well с картофелем фри"
В приложении: создание нового заказа, регистрация пользователя
PATCH — изменить часть заказа: "Можно поменять прожарку на medium rare?"
В личном кабинете: изменить телефон или адрес доставки. Получается, что PATCH — это частичное изменение ресурса.
PUT — полностью переделать заказ: "Вместо стейка я возьму пасту карбонара"
В корзине интернет-магазина: заменить все выбранные товары. То есть PUT — это полная замена ресурса.
DELETE — отменить заказ: "Я передумал, отменяйте мой заказ"
Удаление товара из корзины или отмена подписки
Зачем это нужно не только программистам?
Понимание API помогает:
- Оценить, сколько времени займёт подключение к другому сервису
- Понимать, почему нельзя просто "быстро добавить" какую-то функцию
- Грамотно ставить задачи разработчикам, зная основные возможности и ограничения
- Не растеряться на собеседовании, даже если вы понимаете, как работает API, но объяснить не можете)
Конечно, все эти примеры с ресторанами, официантами и кухнями — утрированные. В реальной разработке всё сложнее: есть авторизация, токены, кэширование, ошибки API (например, 403 и 404) и множество других нюансов, о которых я постараюсь написать попроще. Но если вы — руководитель, менеджер, аналитик или другой специалист, который только начинает разбираться в IT, такие аналогии помогут уловить суть: без API современным сервисам было бы сложнее работать вместе:)
Я начала вести тг канал, где рассказываю просто о сложном в IT. Если вы дочитали этот пост, то скорее всего вас интересует тема, поэтому буду рада, если поддержите подпиской: https://t.me/jer_it
Показать полностью