Если у интервьюера на руках список вопросов и он занимается тем, что сравнивает ответ кандидата с ожидаемым шаблоном (видимо такой тип собеседований вызывает бурления у общественности), то в моем представлении это говорит только о непригодности интервьюера и, видимо, недостаточной зрелости и осознанности компании.
И это не лечится заменой опросника на разбор кейсов. К слову, автор в комментариях сам же и пишет «как правило в этом кейсе я хочу услышать...». Если разбор кейса сводится к получению желаемого результата, то чем это концептуально отличается от стандартных вопросов?
Уверен, что если бы автор проводил собесы в формате: живое знакомство с беседой о прошлой работе, вопросы и задачки на проверку хардов, ответы на вопросы кандидата, то он бы мог делать точно такие же выводы о кандидате, что и сейчас.
В общем, в статье понравилось целеполагание (узнать кандидата со всех сторон, понизить уровень стресса), но причинно-следственные связи описаны неверно. Из-за чего решать проблему предлагается заменой опросника, а не повышением уровня интервьюера, компании, и просвещением соискателей. Что в свою очередь продолжает плодить срачи и нытье в комментариях на тему ненужности тех или иных вопросов на интервью и их форматов.
Так и есть :) Когда писал свой пост, то мои знания были ограничены лишь MVC паттерном и тем, как он применяется в современных веб фреймворках. Но недавно наткнулся на блог Роберта Мартина (Uncle Bob) и прозрел…
Concurrency: Swift 3.0 relies entirely on platform concurrency primitives (libdispatch, Foundation, pthreads, etc.) for concurrency. Language support for concurrency is an often-requested and potentially high-value feature, but is too large to be in scope for Swift 3.0.
А может быть просто стоит написать простейший код без усложнений, а если он устареет, выкинуть его целиком и написать новый опять за несколько минут?
Да, но есть много НО. Например устаревать код может несколько раз за день. Почему нет? И всякий раз его переписывать – извольте. Еще на своей практике пока не встречал людей которые просто брали, выкидывали старое и писали новое. Как правило решение задачи сводилось к навешиванию костылей уже и на без того попахивающий код. В итоге первый программист решил задачу в лоб, второй приделал к этому решению костыль, третий, четвертый, пятый так же оставили свой след. В итоге шестой имеет слабое представление о том, какую задачу на самом деле решает этот код, что из него можно выкинуть, а что нельзя. По итогу вешает сверху свой костыль.
Все, что тут описано, это борьба очень средненького программиста с самим собой и получение им удовольствия от того, что он использовал паттерн, хоть и не к месту, сделал интерфейс, а интерфейсы повышают ЧСВ, это факт, ну и бахнул ИОК по приколу.
Допустим так. Но лучше уж пускай пихает интерфейсы, бахает ИОК, чем всю дорогу будет решать задачи в лоб, заниматься копипастом и при этом называть себя программистом.
Опять же смотря что делать на этих рельсах. Но в целом пять лет воевать с xcode, вникать в тонкости obj-c, изучать эпловские фрэймворки, бороться за каждый мегабайт памяти, за отсутствие лагов и падений, продумывать архитектуру приложения, чтобы вот так вот взять и метнуться на рельсы? Странно это. Я к тому, что человек долгое время изучал инструмент и приучал себя к оптимизациям, а теперь внезапно рельсы. Они-то уж точно не про оптимизацию. Ровно как и другие вебовские приблуды для скриптовых языков.
Если автор под вебом понимает нечто серьезное, то его можно понять. Но если же имеется ввиду всякие там css, js, php, то это явно шаг назад. Отсюда и вопрос.
Спасибо за ваш труд. Как минимум вы помогаете неучам стать чуточку образованней – это уже многого стоит :)
Кстати, этот выпуск обошелся без видео. Предлагаю к просмотру свежачок State, Promises & Reactive Programming :)
А что там со Swift в AppCode? В свое время ушел с AppCode именно из-за возможности получать все самое свежее от эпла. Собственно не жалею. Из плагинов установлены XVim и FuzzyAutocomplete. К навигации по проекту быстро привыкаешь, как оказалось, табы и не нужны вовсе :)
Но наличие методов unBind и removeListener я бы все же оставил, так как иногда действительно нужно отписаться где-то в середине жизненного цикла подписчика.
Вы не можете проверить существование target либо другого объекта, так как при обращении к объекту, который освобожден из памяти, мы получим крэш. Это, если я правильно понял смысл слова «проверяем существование target».
Представлял это как-то так:
class SimpleDynamic<T> {
private weak var target: AnyObject?
private var listener: T -> Void
init(value: T, target: AnyObject, listener: T -> Void) {
self.value = value
self.target = target
self.listener = listener
}
var value: T {
didSet {
if target != nil {
listener(value)
}
}
}
}
По-моему проверка на nil должна работать. Во всяком случае где-то уже подобное видел.
Насчет самостоятельной подписки и отписки: не хотелось бы, чтобы разработчик держал в голове второй пункт.
Насчет потокобезопасности. Да, такое уже есть в Bond, только сегодня заметил. Именно Ваш вариант.
А с потоками такой подход будет работать? Т.е. у нас нечто будет хранить target (ссылка на объект) и callback. При необходимости оповестить слушателей (targets) мы сначала проверяем существование этого target, затем либо удаляем его из списка, либо дергаем callback. Так вот если target удалился в одном потоке, а в этот момент в другом потоке возникла необходимость подергать callback'и, то можно быть уверенным, что все пройдет гладко?
Если у интервьюера на руках список вопросов и он занимается тем, что сравнивает ответ кандидата с ожидаемым шаблоном (видимо такой тип собеседований вызывает бурления у общественности), то в моем представлении это говорит только о непригодности интервьюера и, видимо, недостаточной зрелости и осознанности компании.
И это не лечится заменой опросника на разбор кейсов. К слову, автор в комментариях сам же и пишет «как правило в этом кейсе я хочу услышать...». Если разбор кейса сводится к получению желаемого результата, то чем это концептуально отличается от стандартных вопросов?
Уверен, что если бы автор проводил собесы в формате: живое знакомство с беседой о прошлой работе, вопросы и задачки на проверку хардов, ответы на вопросы кандидата, то он бы мог делать точно такие же выводы о кандидате, что и сейчас.
В общем, в статье понравилось целеполагание (узнать кандидата со всех сторон, понизить уровень стресса), но причинно-следственные связи описаны неверно. Из-за чего решать проблему предлагается заменой опросника, а не повышением уровня интервьюера, компании, и просвещением соискателей. Что в свою очередь продолжает плодить срачи и нытье в комментариях на тему ненужности тех или иных вопросов на интервью и их форматов.
Однажды автор научится есть, а не кушать, после чего возможно его тексты можно будет воспринимать всерьез.
А чего ссылку на оригинал забыли приложить?
github.com/apple/swift-evolution/blob/master/README.md
Меня откровенно коробит продвижение всяких странных дистрибутивов, вместо CentOS.
Да, но есть много НО. Например устаревать код может несколько раз за день. Почему нет? И всякий раз его переписывать – извольте. Еще на своей практике пока не встречал людей которые просто брали, выкидывали старое и писали новое. Как правило решение задачи сводилось к навешиванию костылей уже и на без того попахивающий код. В итоге первый программист решил задачу в лоб, второй приделал к этому решению костыль, третий, четвертый, пятый так же оставили свой след. В итоге шестой имеет слабое представление о том, какую задачу на самом деле решает этот код, что из него можно выкинуть, а что нельзя. По итогу вешает сверху свой костыль.
Допустим так. Но лучше уж пускай пихает интерфейсы, бахает ИОК, чем всю дорогу будет решать задачи в лоб, заниматься копипастом и при этом называть себя программистом.
Кстати, этот выпуск обошелся без видео. Предлагаю к просмотру свежачок State, Promises & Reactive Programming :)
Может все-таки помешает как раз таки отказ от использования интерпретируемого языка :)
Без этого никуда :) Благодарю за советы.
Представлял это как-то так:
По-моему проверка на nil должна работать. Во всяком случае где-то уже подобное видел.
Насчет самостоятельной подписки и отписки: не хотелось бы, чтобы разработчик держал в голове второй пункт.
Насчет потокобезопасности. Да, такое уже есть в Bond, только сегодня заметил. Именно Ваш вариант.