Вообще по моим наблюдениям отношение производительностей дома/в офисе в наибольшей степени зависит от организации домашнего рабочего места и убеждения семьи, что «работа — это работа», остальное — о-малое.
Вообще, при грамотной самомотивации, удачном рабочем и всем-таком личная производительность фрилансера будет значительно выше.
Однако, если вы считаете, что производительность команды равна сумме производительностей ее членов, то вам, скорее всего просто не везло с менеджерами.
При удаленной работе вряд ли может произойти то, что Де Марко называл «кристаллизацией команды»
Так что таки да — удаленная работа хороша в тех случаях, когда задача легко разбивается на атомарные и формальные таски, которые несложно контролировать.
Кровавый же энтерпрайз, да и просто задачи высокой сложности, решаемые таким способом потребуют затрат на контроль соизмеримых со стоимостью разработки.
Так что, кмк — удаленка имеет ограниченную нишу применимости, внутри которой она может развиваться, вне — не очень.
Понравилась идея с забитыми изначально лэйблами, которые просто передвигаете)
Мы, когда решали задачу ускорения отрисовки текста, в итоге остановились на том, что рендерим сами глифы цифр заранее. Их можно даже из памяти не выгружать — этакий bitmap-font, а их накидывать на сцену можно очень и очень быстро. тем более, так как тут только цифры — не будет сильных проблем со стыковкой глифов.
Для этого, даже на уровне инженеров, есть менеджмент рисков.
Навроде того
«за 1 месяц мы этот проект сделаем, если не будет проволочек со стороны А, В и С, вероятность этого, по прошлому опыту можно оценить процентов в 20,
за 3 месяца — в среднем нам удавалось решать аналогичные проблемы, поэтому вероятность успешного завершения я бы оценил в 60 процентов
....»
«функционал, который необходим для продолжения работы над проектом другими командами на достаточном уровне, мы можем сделать за такое-то время, а доведение до блеска займет еще примерно такое время»
И тому подобное)
Таким образом инженер, со своего уровня опыта и экспертизы предоставляет менеджеру возможность выбирать, какой уровень рисков приемлем для проекта и на раннем этапе прогнозировать какие-то изменения (взять еще человека? наладить контакт с вендором превентивно?)
Разумеется, точных процентов не будет, да только вместе с опытом будет расти и точность) И это оставляет возможность инженерам работать, а менеджерам планировать.
Тогда очень мало кого можно назвать программистами :-)
рассмотреть ВСЕ варианты — это что-то навроде взять и написать линукс) Очень мало кто сможет на таком уровне структурировать имеющуюся у него информацию и превратить ее в программный код.
Неужели вы правда верите, что много программистов при должном ресурсе времени и денег в одиночку (или вдвоем) смогут создать что-то подобное?
Физики-ядерщики — как правило еще более круты чем программисты) Как правило, хардкорного советского инженера можно научить кодить, потому что главное — задавать правильные вопросы и искать ответы на них — он уже умеет, а вот наоборот — уже не всегда выходит :-)
Вообще много народу более круты, чем программисты, но если для чистых ученых или инженеров, или медиков, или еще черт-знает-кого уже есть сложенные десятилетиями, устоявшиеся паттерны восприятия остальными (потому что кто-то когда-то многократно так же тратил время на объяснения за стаканчиком пива с мужиками с гаражного кооператива, своим детям, директорам и так далее), а с программистами еще не успели.
Поэтому неудивительно) программисты играют в настольный футбол, ходят по свободному графику, занимаются альпинизмом, курят и при этом получают кучи денег — так что предпосылка для вопроса, как бы есть :-) А вот искать ответы на них умеют, увы, не все.
>— кем вы видите себя через 5 лет? — тут все просто
… Однажды сказал, что через 5 лет вижу себя мировым диктатором :).
Вы знаете, я не HR, а программист, но тем не менее, если бы я проводил собеседование, задал бы вдруг этот вопрос и услышал бы этот ответ — я бы поинтересовался у вас.
-Что вам это даст?
-Что вы для этого делаете?
-Верите ли вы, что предпринимаемые вами действия достаточны для вашей цели?
А когда бы аргументированно показал вам, что ваш ответ дан вами от балды ( о чем вы, разумеется, в курсе ), пояснил бы, что очень хотел узнать, планируете ли вы свою карьеру, есть ли у вас желание развиваться в менеджера через какое-то время или в архитектора, заметно сменить пулл технологий, или вы просто делаете то, что просят? Например, я считаю, что сеньор разработчик и выше, может считать вопрос идиотским, но хотя бы для себя должен уметь на него связно ответить.
Мне ни разу не задавали такой вопрос. Более того, вероятно, во многих компаниях его задают совершенно без задней мысли, просто сверяясь с некой методичкой, но на мой взгляд сам вопрос не так и плох.
Хм… Проверил [UIButton appearance].isProxy — False. Так что вы правы, моя ошибка) Забавно, очень гармонично ложится на такую функциональность как раз NSProxy.
Спасибо за исправление!
Если говорить про этот конкретный пример — игровые элементы майнкрафта отвечают несколько иной топологии, чем элементы современных интегральных схем. Соответственно, хоть логика компоновки и построения схем остается сходной, само пространственное размещение и разбивка по слоям порождает немало интересных задач, которые, потенциально, могут найти применение в нестандартных схемах в реальном мире.
А еще, если говорить про него же — такие вот работы вдохновляют программистов и сочувствующих, восхищают их (нас). Как-то на нас влияют. Так что если это «прожигание электричества», то может и картины — прожигание краски, а музыка — опять же электричества?
Это — творчество, ориентированное на достаточно узкую аудиторию и способ самовыражения.
а haters gonna hate
Да и еще, как правильно отмечал один умный человек — один из важных поинтов взлета автомобиля «Тесла» — в том, что революционное и новое, выглядит как автомобиль, а не как выпускная работа студента дизайнерского факультета.
Если ты презентуешь новую технологию — зачем ломать старые? Тем более те, где, вероятнее всего, недостаточно реального багажа знаний на равноценную замену по ряду параметров (аэродинамика, распределение масс, ремонтопригодность, поведение при столкновениях)
P.S. А в качестве материала — идея интересная, конечно.
Даже если говорить не об игрушках, то при разговоре о кроссплатформе всегда надо перезакладывать и времени и бюджета и вообще. Если ты инди и представления не имеешь о том даже — взлетит твоя идея или нет, то если честно «запустили через 3 месяца и не взлетела» выглядит значительно предпочтительнее, чем «запустили через полгода-год и провалилась».
Если у тебя в мыслях изначально есть кроссплатформа, то я бы рекомендовал просто писать код максимально разделенным на «модули»-«слои», так чтобы замена рендера с UIKit на SpriteKit или Cocos2d решалась за короткий промежуток времени. Так же как и замена физического движка.
Благо, Objective-C дает нам категории и тайпалиасы — соответственно можно делать вид, что разработчик работает с чем-то вообще непривязанным к реализации.
P.S. Восхитительная статья по спрайткиту. Некоторые мои знакомые интересовались стартовыми материалами, теперь я знаю, какую ссылку им скинуть. Спасибо за труд!
Не могу согласиться, что это направление для миграции, так как такого рода синтаксис был с самого начала iOS и всегда был в параллели с alloc-init. Соответственно нет никаких предпосылок, что эта ситуация будет меняться в ту или иную сторону.
К слову — в свифте ситуация с управлением памятью практически такая же, просто не предоставлено явных инструментов для ручного управление (что не говорит, что мы не можем к ним обращаться).
В системах с автоматически управлением памятью каждый объект имеет внутренний счетчик, который увеличивается каждый раз, когда кто-то получает ссылку на этот объект. Когда этот кто-то перестает использовать эту ссылку (например, присваивая Nil), внутренний счетчик объекта уменьшается.
Ну, если быть честным — то с введением ARC ситуация в этой сфере не поменялась вообще — внутренний счетчик был и ранее. ARC просто за программиста расставляет retain и release, не более того.
Ну и <зануда мод> есть еще всякие слабые ссылки, не увеличивающие счетчика, да и вообще </зануда мод>
уже сегодня можно опустить вызов alloc (наример, [NSSting stringWithFormat] работает так же, как [[NSString alloc] initWithFormat:]).
Это тоже очень и очень старая конструкция. Ранее она отличалась от alloc] init] встроенным авторелизом. Не стал бы говорить о том, что это в том или ином роде тенденция.
Может это просто было напоминание, что у каждого метода есть не только «формулировка», но еще и область применимости и граничные условия? :-) Для более сложных задач искушение применить какой-то метод неправильно возрастает несоизмеримо, потому что проверить, даже что «область измерима по Лебегу» порой гораздо утомительнее, чем проверить, что «знаменатель в некоторой окрестности не обращается в 0». Воспринимайте это как напоминание)
Напоминает игру в наперстки — поверить в несоответствие можно только отвлекшись и потеряв нить.
А если говорить про ШТА, то вспоминается, например, парадокс Банаха-Тарского
Огромное спасибо за статью! Объемлющая и глубокая.
Если я правильно понял, то этот подход употребим для практически каждого блока в коде, соответственно возникает вопрос:
В качестве вариантов, которые приходят в голову
-Добавление скрипта во время процессинга .m файлов, который будет по маркеру или просто так обнаруживать блоки и преобразовывать их в нужный вид — тогда можно будет обойтись одним макросом, без замыкающего weakself_end.
-Добавление сниппета/скрипта автоматора c примерно похожим поведением, но явного — который выделенный блок приведет к нужной вам форме?
Вообще по моим наблюдениям отношение производительностей дома/в офисе в наибольшей степени зависит от организации домашнего рабочего места и убеждения семьи, что «работа — это работа», остальное — о-малое.
Однако, если вы считаете, что производительность команды равна сумме производительностей ее членов, то вам, скорее всего просто не везло с менеджерами.
При удаленной работе вряд ли может произойти то, что Де Марко называл «кристаллизацией команды»
Так что таки да — удаленная работа хороша в тех случаях, когда задача легко разбивается на атомарные и формальные таски, которые несложно контролировать.
Кровавый же энтерпрайз, да и просто задачи высокой сложности, решаемые таким способом потребуют затрат на контроль соизмеримых со стоимостью разработки.
Так что, кмк — удаленка имеет ограниченную нишу применимости, внутри которой она может развиваться, вне — не очень.
P.S. Огромное спасибо за код, отличное решение)
Мы, когда решали задачу ускорения отрисовки текста, в итоге остановились на том, что рендерим сами глифы цифр заранее. Их можно даже из памяти не выгружать — этакий bitmap-font, а их накидывать на сцену можно очень и очень быстро. тем более, так как тут только цифры — не будет сильных проблем со стыковкой глифов.
Навроде того
«за 1 месяц мы этот проект сделаем, если не будет проволочек со стороны А, В и С, вероятность этого, по прошлому опыту можно оценить процентов в 20,
за 3 месяца — в среднем нам удавалось решать аналогичные проблемы, поэтому вероятность успешного завершения я бы оценил в 60 процентов
....»
«функционал, который необходим для продолжения работы над проектом другими командами на достаточном уровне, мы можем сделать за такое-то время, а доведение до блеска займет еще примерно такое время»
И тому подобное)
Таким образом инженер, со своего уровня опыта и экспертизы предоставляет менеджеру возможность выбирать, какой уровень рисков приемлем для проекта и на раннем этапе прогнозировать какие-то изменения (взять еще человека? наладить контакт с вендором превентивно?)
Разумеется, точных процентов не будет, да только вместе с опытом будет расти и точность) И это оставляет возможность инженерам работать, а менеджерам планировать.
рассмотреть ВСЕ варианты — это что-то навроде взять и написать линукс) Очень мало кто сможет на таком уровне структурировать имеющуюся у него информацию и превратить ее в программный код.
Неужели вы правда верите, что много программистов при должном ресурсе времени и денег в одиночку (или вдвоем) смогут создать что-то подобное?
Вообще много народу более круты, чем программисты, но если для чистых ученых или инженеров, или медиков, или еще черт-знает-кого уже есть сложенные десятилетиями, устоявшиеся паттерны восприятия остальными (потому что кто-то когда-то многократно так же тратил время на объяснения за стаканчиком пива с мужиками с гаражного кооператива, своим детям, директорам и так далее), а с программистами еще не успели.
Поэтому неудивительно) программисты играют в настольный футбол, ходят по свободному графику, занимаются альпинизмом, курят и при этом получают кучи денег — так что предпосылка для вопроса, как бы есть :-) А вот искать ответы на них умеют, увы, не все.
Вы знаете, я не HR, а программист, но тем не менее, если бы я проводил собеседование, задал бы вдруг этот вопрос и услышал бы этот ответ — я бы поинтересовался у вас.
-Что вам это даст?
-Что вы для этого делаете?
-Верите ли вы, что предпринимаемые вами действия достаточны для вашей цели?
А когда бы аргументированно показал вам, что ваш ответ дан вами от балды ( о чем вы, разумеется, в курсе ), пояснил бы, что очень хотел узнать, планируете ли вы свою карьеру, есть ли у вас желание развиваться в менеджера через какое-то время или в архитектора, заметно сменить пулл технологий, или вы просто делаете то, что просят? Например, я считаю, что сеньор разработчик и выше, может считать вопрос идиотским, но хотя бы для себя должен уметь на него связно ответить.
Мне ни разу не задавали такой вопрос. Более того, вероятно, во многих компаниях его задают совершенно без задней мысли, просто сверяясь с некой методичкой, но на мой взгляд сам вопрос не так и плох.
Спасибо за исправление!
А еще, если говорить про него же — такие вот работы вдохновляют программистов и сочувствующих, восхищают их (нас). Как-то на нас влияют. Так что если это «прожигание электричества», то может и картины — прожигание краски, а музыка — опять же электричества?
Это — творчество, ориентированное на достаточно узкую аудиторию и способ самовыражения.
а haters gonna hate
Если ты презентуешь новую технологию — зачем ломать старые? Тем более те, где, вероятнее всего, недостаточно реального багажа знаний на равноценную замену по ряду параметров (аэродинамика, распределение масс, ремонтопригодность, поведение при столкновениях)
P.S. А в качестве материала — идея интересная, конечно.
Если у тебя в мыслях изначально есть кроссплатформа, то я бы рекомендовал просто писать код максимально разделенным на «модули»-«слои», так чтобы замена рендера с UIKit на SpriteKit или Cocos2d решалась за короткий промежуток времени. Так же как и замена физического движка.
Благо, Objective-C дает нам категории и тайпалиасы — соответственно можно делать вид, что разработчик работает с чем-то вообще непривязанным к реализации.
P.S. Восхитительная статья по спрайткиту. Некоторые мои знакомые интересовались стартовыми материалами, теперь я знаю, какую ссылку им скинуть. Спасибо за труд!
К слову — в свифте ситуация с управлением памятью практически такая же, просто не предоставлено явных инструментов для ручного управление (что не говорит, что мы не можем к ним обращаться).
Ну, если быть честным — то с введением ARC ситуация в этой сфере не поменялась вообще — внутренний счетчик был и ранее. ARC просто за программиста расставляет retain и release, не более того.
Ну и <зануда мод> есть еще всякие слабые ссылки, не увеличивающие счетчика, да и вообще </зануда мод>
Это тоже очень и очень старая конструкция. Ранее она отличалась от alloc] init] встроенным авторелизом. Не стал бы говорить о том, что это в том или ином роде тенденция.
А если говорить про ШТА, то вспоминается, например, парадокс Банаха-Тарского
Если я правильно понял, то этот подход употребим для практически каждого блока в коде, соответственно возникает вопрос:
В качестве вариантов, которые приходят в голову
-Добавление скрипта во время процессинга .m файлов, который будет по маркеру или просто так обнаруживать блоки и преобразовывать их в нужный вид — тогда можно будет обойтись одним макросом, без замыкающего weakself_end.
-Добавление сниппета/скрипта автоматора c примерно похожим поведением, но явного — который выделенный блок приведет к нужной вам форме?