Что мешает выбрать несколько? В любом случае возможно придется: сейчас модно совсем отделять фронтенд от бекенда, где на фронтенде монстр типа ангуляра/реакта/ембера/что-там-щас-модно, со своими приблудами для сборки. Соответственно бекенд превращается в API, и API можно городить совсем по разному: хоть по отдельному сервису на каждый вызов :) При этом: не понравится — можно кусочно заменять.
Тоже не люблю таскать окна туда-сюда, хотя мак как-то и пытается запоминать расположение, временами. Приспособил внешний монитор для логов: там отдельный терминал, чтобы не путаться в переключении окон — совсем отдельный, типа iTerm2 vs. Terminal.app, со своими настройками шрифтов — побольше, чтобы не надо было вглядываться издали. Когда нужно — можно перевести взгяд, посмотреть, когда не нужно — ну и нафиг, не путается под ногами. Пробовал выносить на другой монитор дебагер из браузера — но это как-то менее удобно, хотя иногда тоже ничего.
Например на том что гомофобия у нас часто оправдывается тем что «ми християнська країна», мол не надо нам этого. Или например на том что всякая толерантность одних церквей к другим, даже в рамках того же христианства, исчезает как только они начинают делить имущество. Сколько там наши православные церкви грызутся между собой? Что уж там говорить о толерантности к другим религиям, если они в рамках одного течения своей собственной не могут договориться?
Христианство не то что не толерантно, оно часто используется как дополнительный аргумент/инструмент, при навязывании норм морали. Потому что если просто «не правильно» — то это только ваша точка зрения, а если уж «не по христиански» (что бы это не значило) — значит «кто не с нами, тот против нас», а «нас» дофига.
Так, простите, церковь сама по себе не толерантна, поэтому требовать толерантного отношения к ней — это как странно.
Это вы не по адресу, за Vala +500 не получится :)
Как по мне: самая большая проблема местных IT-ивентов с местными же докладчиками: зачитывание документации вслух и рассказы о каких-то примитивных вещах, наложенных на конкретные реализации, как о чем-то выдающемся. Ну не может
Зависит от команды. Если ты попадешь в коллектив, где все, или подавляющее большинство говорит на языке паттернов — придется знать, ибо ничего не поймешь. Если нет — паттерны превращаются просто в список эффектов которых можно добиться, полезно, например для того чтобы знать что гуглить :), но не критично. Часто оказывается так что «я так всегда делал, а оказывается для этого есть умное обозначение».
Лишь бы взять и запретить. Почему бы для начала не закрепить сложившийся статус-кво. Есть частные предприниматели — те самые «деятельность на свой страх и риск», возможность нанимать работников — создавать рабочие места итп, есть контракторы — что-то среднее между наемным работником и предпринимателем, типа нет защиты по КЗоТу, деятельность в рамках договора, но «постоянный» договор и де-факто один источник дохода в единицу времени, ну и наемные работники с КЗоТом и прочим. Риски разные, вовлеченность/защита государства разная, соответственно разные ставки налогов, больше рисков — меньше налогов. Ну там
Для того чтобы не нарушать обещаний, их не нужно давать :)
А если серьезно: одна из самых существенных проблем связанных с естимейтами (за исключением оптимизма, есс-но) — это то что умолчательно предполагается что естимейт — это ответ на вопрос «сколько времени ты будешь писать код», в то время как используется это значение для оценки того «когда проблема будет решена». То есть, если ты говоришь что фигня вопрос — работы на два часа, то при сорокачасовой рабочей недели мы собираем 20 тасков, и ... удачи :) Ну или берем 6 «effective hours/day», и получаем 15 тасков. Забывая о стэндапах, митингах, помощи коллеге или собственным просьбах помочь, внешних и внутренних зависимостях, и еще о вагоне и маленькой тележке вещей на которые тратится время. А еще это нужно протестировать, куда-то задеплоить, возможно посмотреть на ошибки. А еще возможно надо подумать, возможно надо время въехать в задачу. В итоге писать код ты возможно таки будешь те же два часа, а вот потратишь — пол дня — день.
При определенной доле желания самих обучаемых — почему нет. Ну то есть, если это стандартный «наш» подход, когда ученик отваливает некоторое количество бабла, приходит на курсы, складывает лапки, и типа все, ждет когда учитель впихнет в него разумное/доброе/вечное, — так есс-но ничего не получится.
Тем более там не стоит задачи подготовить абстрактного синьйора для работы в Google или Facebook. Там стоит задача подготовить младшего специалиста, который способен работать с стандартными инструменты, типа той же JIRA. При этом если там даже какие-то несчастным 30% этими инструментами пользуются — это вполне себе круто, компаний там дофига, на всех хватит. Это Win-Win в какой-то степени: компании получают людей которые звезд с неба не хватают, но могут приносить пользу прямо сейчас, люди получают работу и опыт.
Классическая ситуация:
— Хочу трактор, отговорите меня
— Чего это я тебя буду отговаривать?
SOLID, паттерны — это как раз штуки которые могут быть составной частью этой самой интуиции. Это интересно как раз с точки зрения структурирования опыта. Типа всегда делал так, или обходил острые углы, а тут это систематизировано. Конечно, если смотреть на это с точки зрения «заучил» и «пытаюсь формально впихнуть во все дыры», то получается фигня.
вроде ок:
— Наличие опыта работы с любым объектным языком программирования
— Базовое знание Java будет плюсом
Но вам виднее :) я про SalesForce тока слышал :)
Ok, в рамках Вашей аналогии. Допустим у нас есть интерфейс:
$myBoiler->setDesirableTemperature($temp); $myBoiler->setDesirableAmountOfWater($amount); $myBoiler->heatWater();То есть подходите вы к бойлеру, и крутилками на нем говорите: на какую температуру подогреть воду, сколько воды греть, а потом жмакаете большую красную кнопку «подогреть». Причем, возможен и обратный вариант использования:
$myBoiler->setDesirableAmountOfWater($amount); $myBoiler->setDesirableTemperature($temp);нам ведь по сути пофигу в каком порядке крутить крутилки, если большая красная кнопка не нажата.
И тут мы получаем ваш же С-нагреватель, у которого собственно большой красной кнопки нет, ее роль выполняет крутилка «setTemperature» — то есть как только у этой крутилки выставляем температуру — он начинает греть.
Далее делаем ровно тоже самое что сделали вы: для С-нагревателя heatWater — пустой, а setDesirableTemperature — фактически греет воду. По-сути нарушая контракт «установка значения просто устанавливает значение, но не греет воду». И получаем сюрприз: в ряде случаев все хорошо, а в ряде случаев ба-бах (воды еще нет, а мы ее уже греем).
Собственно вот вам и нарушение принципа: heatWater — не работает, а setDesirableTemperature греет воду. То есть подтип не может быть использован без знаний о его особенностях. Пофиксить тоже просто: setDesirableTemperature — должно устанавливать не крутилку, а просто сохранять внутреннее значение, а heatWater — устанавливать крутилку — то есть начинать греть. Тогда внешние контракты будут соблюдаться.
Так как раз SOLID — это прежде всего на тему «как надо спроектировать», а не «как надо подбивать костыли и подпорки». Когда надо подбивать костыли и подпорки, SOLID уже проиграл.
Забавно, реализуем API с кишками наружу:
while($myBoiler->getWaterTemperature() < $myBoiler->getDesirableTemperature()) { $myBoiler->heatWater(); }то есть рассказываем клиенту о том как бойлер на самом деле греет воду, и предлагаем клиенту следить за этим процессом самостоятельно. То есть, блин, это проблемы с банальной инкапсуляцией.
После чего, бугага, целиком логично получаем «по лбу» в виде просто другого процесса подогрева, но в итоге все-равно продолжаем размышлять как сохранить изначально кривой интерфейс. Ведь если бы банально весь подогрев заключался бы в:
$myBoiler->setDesirableTemperature($temp) $myBoiler->heatWater();или даже просто:
$myBoiler->heatWater($temp);все, никаких проблем.
Войти-в-айти, the hard way.
не хочу испортить праздник, но: en.wikipedia.org/... in#Awards_and_recognition
«2009: Grammy Award for Best Instrumental Soloist(s) Performance (with orchestra)»