в 90-е, заводы и предприятия, которые так и не научились продавать на свободном рынке, за неимением денег, выдавали иногда зарплату рабочим продукцией.
это была достойная зарплата?
нет, я понимаю что вы имели ввиду что нибудь простенькое типа рабочие в lamborgini должны иметь возможность позволить себе эти машины. но мир чуть сложнее. кроме довольно простых вещей типа "это умышленный предмет роскоши", к более сложным (какой продукт у учителей?) до абсурдрых (ассенизаторам не нравится ваше определение, совсем).
вообще, по моим наблюлениям, вой про "достойную зарплату" переводится как "мало денег, хочу больше". и в этом в целом нет ничего плохого, кроме попытки манипуляции. ну мало тебе денег - поменяй работодателя, работу, страну, профессию, расти профессионально. если и это не помогает значит жадность выше чем возможности. или работай над собой или займись инвестициями или бизнесом или стань таким крутым специалистом которым сразу платят акциями и много. но нет, разводят сопли про "справедливость", "достойную" зарплату. некоторые настолько увлекаются что начинают сами верить что начальство крадет деньги с из зарплат чтобы купить себе теслу.
никогда не понимал что такое "достойная зарплата". что это? как ее считать? есть ли формулы или другие механизмы подсчета? по каким параметрам можно оценить достойная она или нет?
я добавлю что ко всему вышеперечисленному принцип должен быть в достаточной мере однозначен. если его трактуют по разному пользы от него мало. solid не принцип а набор принципов. что уже перебор, фраза "код не соответствует solid" не даёт информации без разъяснений. но дело еще в том что многие из этого набора принципов можно толковать по разному, даже в одном стэке технологий. и толкуют. думаю вы сталкивались, не раз. а в разных стэках вообще беда. и получается что это просто принципы для собесов, как точка начала общения по архитектуре, и принципы для очень общего понимания хороших практик где то на уровне начинающего мидла, после длинных статей разъяснений о чем же на самом деле solid.
обожаю принципы SOLID, у них столько разных толкований. ведь это то что нужно от паттернов и принципов разработки, чтобы можно было поспорить над куском кода насколько он солид и в какой трактовке.
я это слышал буквально про все. фреймворки, архитектурные приёмы, языки, инструменты, подходы. даже про ООП такое слышал, раз десять. ещё раз : отказываться от чего-то категорически, так же нелепо как и следовать чему-то категорически. мастерство программиста, его главный "опыт" это что, почему и как применить для решения задачи. есть ещё майндсет но это не относится к тебе беседы, поэтому основным будем считать этот навык.
и как не применять. с микросервисами можно накосячить. с монолитом можно накосячить (вообще легко, пару лет активной разработки на пару команд без жёстких и всем понятных стандартов и "успех" гарантирован). с архитектурой и ООП накосячить вообще легко. без них не накосячить на крупном проекте почти невозможно. но если уметь все это использовать и понимать плюсы, минусы и риски то можно не косячить. это все инструменты, и вы выбираете их в зависимости от задачи, и правильно используете. не забивайте гвозди пассатижами, не закручивайте шурупы ножом, когда используете молоток аккуратнее с пальцами, гвозди в керамичкскую плитку плохая идея. ударили себе по пальцам молотком - учитесь им пользоваться а не кричите что гвозди зло. ударили вам по пальцам - та же фигня, виноват тот. кто держит молоток а не гвозди с молотком. внезапно, да?
а что у вас за стороны? вы там что за лайки и аудиторию боретесь? где? и зачем тогда вы отзеркаливаете этого "адепта тикток" и несёте такой же неаргументированный эмоциональный поток сознания, не имеющий никакой практической и теоретической польщы? чтобы думать не надо было? в чем смысл этот "сражения"?
ожидание : анализ преимуществ, недостатков и тонких моментов (микро) сервисной архитектуры. рекомендации где и когда использовать (а где нет) , на что обратить внимание и как не сделать только хуже.
реальность: ирония, ролик про тупого разработчика, кривые аналогии, ирония, чуть получше аналогии, экскурс в историю, ведро сарказма, я путаю архитектуру приложения/проекта и архитектуру кода но это не страшно, опа экономика и менеджмент, "соскучились по сарказму? ловите", начинать можно с монолита (спасибо кэп! это так неожиданно. ), "а что если вместо микросервисов использовать ООП".
хотите открою великий секрет разработки? : silver bullet не существует.
хотите второй? : каждый инструмент и подход имеет смысл в определённых условиях и будучи правильно использованным. понимание где и как их использовать и есть главный навык разработчика.
только тсс, никому, это тайна известная лишь избранным.
в целом ничего. если программист генерирует именно болванку, самую минимальную . которую потом доработает. полностью понимая протокол, его формат и логику. то есть просто сэкономит время и усилия. но ведь он может (и даже скорее всего) сгенерить и не будет разбираться.
и так же поступит тот кто сгенерит WSDL по серверу.
и тот кто модифицирует сервер и перегеннерит WSDL, не особо заботясь об удобстве, гибкости, обратной совместимости и прочих вещах что прощают жизнь клиентам и серверу.
и встанут они на дорогу в ад под названием "что за мерзкая жижа была вместо мозга у тех кто проектировать это API?!" и весело пойдут по ней, год за годом приближая армагедон.
ведь мы же об API говорим, часто внешнем, и у него могут быть сотни потребителей, так ведь. которым приходится адаптироваться при изменении формата, да?
видели когда нибудь API которое никто не может поменять потому что не знает толком как оно работает, и чем клиенты пользуются. я видел. много. среди soap почти все такое.
потому что его тяжело читать, легко переусложнить, мало кто пытается разобраться или заложить прочности в начале, только добавляют, ещё больше усложняя, и все, блин, генерируют код. WSDL по серверу, клиента по WSDL, сервер по WSDL, и заново по кругу. и никто в душе не одупляет зачем нужны вот эти параметры и объекты, зато типы описаны, ссылки на подтипы висят на сервера которые уже давно не работают, чтобы сделать первый запрос нужна неделя изучения всех файлов (включая по ссылкам, которых нет), а когда созваниваться с "той стороной" встречаешь непонимание, они знают свою систему, знают сервер, но уже формат API они не знают, зачем, вот же wsdl есть. который никто не читал и не может прочитать. спрашиваешь кто проектировал и выясняется что по сути никто, джун написал первые пару функций и сгенерил код, а потом лет 10 добавляли по ситуации в общее api то что нужно одному клиенту из 100. а сейчас даже добавлять не будут потом у что генератор уже этот комок ссылок не тянет. почему изначально не спроектировали нормально? а у них некому, генераторы же есть, никто API никогда не проектировал. и вообще мы в банке работаем, у нас тут секьюрность, протоколы, бумажки, отчеты, некогда нам.
генерация расслабляет. генерировать можно болванки, на самом минимальном уровне. генерация реального кода это хуже чем безумные копипасты с stackoverflow джуном, там хотя бы джун задуматься на пол секунды прежде чем вставлять, да и можно объяснить ему что он не прав. генерация же это вредренный рабочий процесс. ты не можешь быть не прав и тебе не нужно разбиратся потому что зачем, месть генератор, он там что то шуршит, если неправильно то виноват тот кто написал этот генератор, 10 лет назад и для совершенно другого проекта. а тебе надо просто сгенерить и воткнуть пару костылей чтобы закрыть таску.
XML со всей инфраструктурой изначально был ошибкой, попыткой сделать максимально гибко и универсально и при этом же навернуть инструментов для максимального контроля формата, и все это в одном формате текстового файла, с структурой которая совместима только с объектными типами, но используется для передачи такого количества данных что в большинстве случаев парсить его целиком в одну обьектную модель это наверняка сожрать всю память и упасть.
SOAP наверное самое нелепое детище этого подхода. а давайте сделаем RPC и в качестве контейнеров используем XML, и сделаем специальный формат файлов для описания контейнеров, функций и взаимодействий. И тоже на XML. и ещё внутренние типы будем создавать, и их описывать. а чтобы стало совсем универсально и переиспользование, позволим этим описаниям включать и ссылать ся на другие описания в интернете. и чтобы совсем плохо было засунем в эти WSDL столько сложностей что новичку чисто чтобы понять структуру сложного запроса придётся разбиратся неделю. ну и потом ещё версий протокола наделаем чтобы совместимость совсем уничтожить. место SOAP в 1980-х, максимум в 1990-х, но почему то в консервативных организациях типа банков и гос учреждений он ещё местами жив.
в SOAP нет ни одного преимущества перед REST (с json), и куча недостатков.
Вот же молодёжь пошла, XSLT не видели, SOAP не пробовали, WSDL файлов не читали и на Smarty не верстали. Да знаете ли вы что тако DOM и как использовать алерты для отладки js? верстали ли вы таблицами? Вскакивали ли вы ночью с постели потому что вам приснилось что вышла новая версия ExtJs и как всегда без документации, и вам снова надо все переделывать, а никто не знает как оно теперь работает? Юзали ли вы ифреймы чтобы постучатся на сервер и радовались ли AJAX? я что вы почувствовали когда узнали о JQuery?! ждали ли когда наконец то умрёт IE6? а после снова ждали. и снова.
зажрались, XSLT им сложный и непонятный, а кто то целые новые языки, cms и фреймворки на почти чистом XML писал и развивал. эх, были же времена, какой фигнёй только не страдали (уходит в закат бормоча что то про траву и деревья).
а, ок, с то при прочтении почему то воспринимается как классика жанра: слей пару сотен адресов через CC в письме про безопасность и персональные данные, а потом удивляйся почему тебя не воспринимают серьёзно.
имхо стоит уточнить в статье, не один я так это воспринял.
ну и в целом, учения и проверки без предупреждения это конечно более объективно, но ведь бесит же. вы же понимаете что бесит? люди мобилизуются, в стрессе ищут и решают проблему, ищут на что могло повлиять, что могло утечь. часто это не просто и требует проверки буквально всего и не по разу, потому что одно дело взлом а другое взлом который частично или полностью не заметили и не приняли меры. а потом приходите вы и радостно "это учения, вы прошли, а давайте анализировать результаты". вполне понимаю желание что нибудь и в вашей епархии уронить чтобы вы тоже по тренировались и повысили свои навыки. короче тут думать надо прежде чем делать втихую, очень хорошо все взвешивать. плюсы, минусы, стоит ли одно другого. и не забывать про мальчика который кричал "волки, волки!".
P. S. чаще всего айтишников бесят не столько проверки сколько некорректная подборка обучающих материалов и треннингов. особенно если она дилетантская и не актуальная. когда ты веб разработчик, а тебе приходится проходить интерактивный урок в духе "проверь домен в адресе отправителя" то сначала конечно ржачно а потом грустно (надеюсь вы вкурсе что поле from сумеет подделать даже джун вообще не учившийчюся безопасности). и бесит. особенно если скипнуть нельзя. знаете такие видео уроки с проверками, по две-три минуты, и не проскролишь, и не отойдешь пока оно крутится там себе, и ничего нового не узнаешь, и хочется написать письмо безопаснику и HR о том что это обходится на раз-два, но знаешь что это все равно бесполезно, если бы он/она умел думать он бы не включил подобные уроки в обязательный онбординг для всех.
а можно подробнее про "во время учений для своего удобства я выгрузила базу всех сотрудников из системы управления персоналом — с именами, должностями, почтовыми адресами. Затем по невнимательности вся эта информация попала в рассылку в заголовках письма каждому с его ФИО и должностью."?
в 90-е, заводы и предприятия, которые так и не научились продавать на свободном рынке, за неимением денег, выдавали иногда зарплату рабочим продукцией.
это была достойная зарплата?
нет, я понимаю что вы имели ввиду что нибудь простенькое типа рабочие в lamborgini должны иметь возможность позволить себе эти машины. но мир чуть сложнее. кроме довольно простых вещей типа "это умышленный предмет роскоши", к более сложным (какой продукт у учителей?) до абсурдрых (ассенизаторам не нравится ваше определение, совсем).
вообще, по моим наблюлениям, вой про "достойную зарплату" переводится как "мало денег, хочу больше". и в этом в целом нет ничего плохого, кроме попытки манипуляции. ну мало тебе денег - поменяй работодателя, работу, страну, профессию, расти профессионально. если и это не помогает значит жадность выше чем возможности. или работай над собой или займись инвестициями или бизнесом или стань таким крутым специалистом которым сразу платят акциями и много. но нет, разводят сопли про "справедливость", "достойную" зарплату. некоторые настолько увлекаются что начинают сами верить что начальство крадет деньги с из зарплат чтобы купить себе теслу.
не понимаю.
ну не получается писать в стихах, напиши в прозе. обычным текстом. нет, это не стыдно. это же пост, а не поздравление с юбилеем.
не понимаю.
никогда не понимал что такое "достойная зарплата". что это? как ее считать? есть ли формулы или другие механизмы подсчета? по каким параметрам можно оценить достойная она или нет?
если это шутка то я не уловил её соль. объясните где лопата, пожалуйста.
если это серьёзно то я офигел, сказал что хабр уже не торт и тихо слился. объяснений в этом случае не надо.
так, господа, я официально заявляю, не все пхпшники такие. эти случайность. простите, недоглядели. те кто выпустил его в интернет будут наказаны.
я добавлю что ко всему вышеперечисленному принцип должен быть в достаточной мере однозначен. если его трактуют по разному пользы от него мало. solid не принцип а набор принципов. что уже перебор, фраза "код не соответствует solid" не даёт информации без разъяснений. но дело еще в том что многие из этого набора принципов можно толковать по разному, даже в одном стэке технологий. и толкуют. думаю вы сталкивались, не раз. а в разных стэках вообще беда. и получается что это просто принципы для собесов, как точка начала общения по архитектуре, и принципы для очень общего понимания хороших практик где то на уровне начинающего мидла, после длинных статей разъяснений о чем же на самом деле solid.
обожаю принципы SOLID, у них столько разных толкований. ведь это то что нужно от паттернов и принципов разработки, чтобы можно было поспорить над куском кода насколько он солид и в какой трактовке.
а что это?
каких олдов? вы про что вообще? тут что теперь длиной опыта меряются? ну доставайте, чего уж тогда, я за линейкой схожу.
я это слышал буквально про все. фреймворки, архитектурные приёмы, языки, инструменты, подходы. даже про ООП такое слышал, раз десять. ещё раз : отказываться от чего-то категорически, так же нелепо как и следовать чему-то категорически. мастерство программиста, его главный "опыт" это что, почему и как применить для решения задачи. есть ещё майндсет но это не относится к тебе беседы, поэтому основным будем считать этот навык.
и как не применять. с микросервисами можно накосячить. с монолитом можно накосячить (вообще легко, пару лет активной разработки на пару команд без жёстких и всем понятных стандартов и "успех" гарантирован). с архитектурой и ООП накосячить вообще легко. без них не накосячить на крупном проекте почти невозможно. но если уметь все это использовать и понимать плюсы, минусы и риски то можно не косячить. это все инструменты, и вы выбираете их в зависимости от задачи, и правильно используете. не забивайте гвозди пассатижами, не закручивайте шурупы ножом, когда используете молоток аккуратнее с пальцами, гвозди в керамичкскую плитку плохая идея. ударили себе по пальцам молотком - учитесь им пользоваться а не кричите что гвозди зло. ударили вам по пальцам - та же фигня, виноват тот. кто держит молоток а не гвозди с молотком. внезапно, да?
а что у вас за стороны? вы там что за лайки и аудиторию боретесь? где? и зачем тогда вы отзеркаливаете этого "адепта тикток" и несёте такой же неаргументированный эмоциональный поток сознания, не имеющий никакой практической и теоретической польщы? чтобы думать не надо было? в чем смысл этот "сражения"?
ожидание : анализ преимуществ, недостатков и тонких моментов (микро) сервисной архитектуры. рекомендации где и когда использовать (а где нет) , на что обратить внимание и как не сделать только хуже.
реальность: ирония, ролик про тупого разработчика, кривые аналогии, ирония, чуть получше аналогии, экскурс в историю, ведро сарказма, я путаю архитектуру приложения/проекта и архитектуру кода но это не страшно, опа экономика и менеджмент, "соскучились по сарказму? ловите", начинать можно с монолита (спасибо кэп! это так неожиданно. ), "а что если вместо микросервисов использовать ООП".
хотите открою великий секрет разработки? : silver bullet не существует.
хотите второй? : каждый инструмент и подход имеет смысл в определённых условиях и будучи правильно использованным. понимание где и как их использовать и есть главный навык разработчика.
только тсс, никому, это тайна известная лишь избранным.
в целом ничего. если программист генерирует именно болванку, самую минимальную . которую потом доработает. полностью понимая протокол, его формат и логику. то есть просто сэкономит время и усилия. но ведь он может (и даже скорее всего) сгенерить и не будет разбираться.
и так же поступит тот кто сгенерит WSDL по серверу.
и тот кто модифицирует сервер и перегеннерит WSDL, не особо заботясь об удобстве, гибкости, обратной совместимости и прочих вещах что прощают жизнь клиентам и серверу.
и встанут они на дорогу в ад под названием "что за мерзкая жижа была вместо мозга у тех кто проектировать это API?!" и весело пойдут по ней, год за годом приближая армагедон.
ведь мы же об API говорим, часто внешнем, и у него могут быть сотни потребителей, так ведь. которым приходится адаптироваться при изменении формата, да?
видели когда нибудь API которое никто не может поменять потому что не знает толком как оно работает, и чем клиенты пользуются. я видел. много. среди soap почти все такое.
потому что его тяжело читать, легко переусложнить, мало кто пытается разобраться или заложить прочности в начале, только добавляют, ещё больше усложняя, и все, блин, генерируют код. WSDL по серверу, клиента по WSDL, сервер по WSDL, и заново по кругу. и никто в душе не одупляет зачем нужны вот эти параметры и объекты, зато типы описаны, ссылки на подтипы висят на сервера которые уже давно не работают, чтобы сделать первый запрос нужна неделя изучения всех файлов (включая по ссылкам, которых нет), а когда созваниваться с "той стороной" встречаешь непонимание, они знают свою систему, знают сервер, но уже формат API они не знают, зачем, вот же wsdl есть. который никто не читал и не может прочитать. спрашиваешь кто проектировал и выясняется что по сути никто, джун написал первые пару функций и сгенерил код, а потом лет 10 добавляли по ситуации в общее api то что нужно одному клиенту из 100. а сейчас даже добавлять не будут потом у что генератор уже этот комок ссылок не тянет. почему изначально не спроектировали нормально? а у них некому, генераторы же есть, никто API никогда не проектировал. и вообще мы в банке работаем, у нас тут секьюрность, протоколы, бумажки, отчеты, некогда нам.
генерация расслабляет. генерировать можно болванки, на самом минимальном уровне. генерация реального кода это хуже чем безумные копипасты с stackoverflow джуном, там хотя бы джун задуматься на пол секунды прежде чем вставлять, да и можно объяснить ему что он не прав. генерация же это вредренный рабочий процесс. ты не можешь быть не прав и тебе не нужно разбиратся потому что зачем, месть генератор, он там что то шуршит, если неправильно то виноват тот кто написал этот генератор, 10 лет назад и для совершенно другого проекта. а тебе надо просто сгенерить и воткнуть пару костылей чтобы закрыть таску.
ёжики плакали, кололись, но продолжали генерировать код.
громоздкий, неудобный, не гибкий, тяжёлый.
XML со всей инфраструктурой изначально был ошибкой, попыткой сделать максимально гибко и универсально и при этом же навернуть инструментов для максимального контроля формата, и все это в одном формате текстового файла, с структурой которая совместима только с объектными типами, но используется для передачи такого количества данных что в большинстве случаев парсить его целиком в одну обьектную модель это наверняка сожрать всю память и упасть.
SOAP наверное самое нелепое детище этого подхода. а давайте сделаем RPC и в качестве контейнеров используем XML, и сделаем специальный формат файлов для описания контейнеров, функций и взаимодействий. И тоже на XML. и ещё внутренние типы будем создавать, и их описывать. а чтобы стало совсем универсально и переиспользование, позволим этим описаниям включать и ссылать ся на другие описания в интернете. и чтобы совсем плохо было засунем в эти WSDL столько сложностей что новичку чисто чтобы понять структуру сложного запроса придётся разбиратся неделю. ну и потом ещё версий протокола наделаем чтобы совместимость совсем уничтожить. место SOAP в 1980-х, максимум в 1990-х, но почему то в консервативных организациях типа банков и гос учреждений он ещё местами жив.
в SOAP нет ни одного преимущества перед REST (с json), и куча недостатков.
а жаль
Вот же молодёжь пошла, XSLT не видели, SOAP не пробовали, WSDL файлов не читали и на Smarty не верстали. Да знаете ли вы что тако DOM и как использовать алерты для отладки js? верстали ли вы таблицами? Вскакивали ли вы ночью с постели потому что вам приснилось что вышла новая версия ExtJs и как всегда без документации, и вам снова надо все переделывать, а никто не знает как оно теперь работает? Юзали ли вы ифреймы чтобы постучатся на сервер и радовались ли AJAX? я что вы почувствовали когда узнали о JQuery?! ждали ли когда наконец то умрёт IE6? а после снова ждали. и снова.
зажрались, XSLT им сложный и непонятный, а кто то целые новые языки, cms и фреймворки на почти чистом XML писал и развивал. эх, были же времена, какой фигнёй только не страдали (уходит в закат бормоча что то про траву и деревья).
А где HTML, CSS, XML, JSON, EXCEL, WORD, и владение компьютером Windows на уровне уверенного пользователя?
меня одного коробит от постоянного ТЗ как "тестовое задание" в тексте?
а, ок, с то при прочтении почему то воспринимается как классика жанра: слей пару сотен адресов через CC в письме про безопасность и персональные данные, а потом удивляйся почему тебя не воспринимают серьёзно.
имхо стоит уточнить в статье, не один я так это воспринял.
ну и в целом, учения и проверки без предупреждения это конечно более объективно, но ведь бесит же. вы же понимаете что бесит? люди мобилизуются, в стрессе ищут и решают проблему, ищут на что могло повлиять, что могло утечь. часто это не просто и требует проверки буквально всего и не по разу, потому что одно дело взлом а другое взлом который частично или полностью не заметили и не приняли меры. а потом приходите вы и радостно "это учения, вы прошли, а давайте анализировать результаты". вполне понимаю желание что нибудь и в вашей епархии уронить чтобы вы тоже по тренировались и повысили свои навыки. короче тут думать надо прежде чем делать втихую, очень хорошо все взвешивать. плюсы, минусы, стоит ли одно другого. и не забывать про мальчика который кричал "волки, волки!".
P. S. чаще всего айтишников бесят не столько проверки сколько некорректная подборка обучающих материалов и треннингов. особенно если она дилетантская и не актуальная. когда ты веб разработчик, а тебе приходится проходить интерактивный урок в духе "проверь домен в адресе отправителя" то сначала конечно ржачно а потом грустно (надеюсь вы вкурсе что поле from сумеет подделать даже джун вообще не учившийчюся безопасности). и бесит. особенно если скипнуть нельзя. знаете такие видео уроки с проверками, по две-три минуты, и не проскролишь, и не отойдешь пока оно крутится там себе, и ничего нового не узнаешь, и хочется написать письмо безопаснику и HR о том что это обходится на раз-два, но знаешь что это все равно бесполезно, если бы он/она умел думать он бы не включил подобные уроки в обязательный онбординг для всех.
а можно подробнее про "во время учений для своего удобства я выгрузила базу всех сотрудников из системы управления персоналом — с именами, должностями, почтовыми адресами. Затем по невнимательности вся эта информация попала в рассылку в заголовках письма каждому с его ФИО и должностью."?