Например в событии было сначала только Name, а потом разделилось на LastName, FirstName. Хотя событие остается одно и то же, пусть будет RenameSomething().
Это ведь real-world case
Про версии событий детальнее хочется услышать. Чтобы были примеры граблей, на которые можно наступить, если версии не использовать или использовать не верно.
В Lokad, как я вижу, версия используется для снэпшота, чтобы определить к какому снэпшоту применять/восстанавливать события, так?
Но ведь и сами события могут изменятся в процессе разработки, а стек событий уже может быть в базе и при большом восстановлении с нуля, возникает проблема конвертации.
Хочется больше информации на этот счет с примерами. Так как теоретического материала много, но как-то это вскользь все рассматривается.
Мм… на другой машине все заработало как надо, все галки стояли. Видимо проблема в локальной машине где-то в настройках старых может или еще какое-нито неудачное стечение обстоятельств.
Вопрос снимается.
У меня вопрос: Ctrl+click по классу/методу так и не ведет к определению класса/метода?
финальный билд ReSharper, VS12 RC 11.0.50706.0
до этого регулярно ставил nightly build
система Win7 x64
Большая часть традиций было в Интеле, средний возраст команды 26, самому младшему 22, самому старшему 37 или около того. К слову, больше всего отжигали как раз возрастные сотрудники.
В других старался привнести похожие вещи и в целом удавалось, возраст был примерно тоже в районе 25.
Практически любая инициатива спущенная сверху не сработает. Все зависит от желания и возможностей коллектива. Если будет запрос от коллектива на пятничный бухач, то можно подумать, если нет такой потребности, инициатива сверху будет саботирована или же сильно не понята.
Традиции были такие:
Настольные игры после обеда. За полчаса можно было сыграть партию. Так же были настольные игры по пятницам. Очень помогало сплотить коллектив и лояльнее относишься ко всем коллегам.
В той же компании летом собирались по выходным, пекли печеньки и опять же играли в настолки.
В конце релизов были походы в рестораны от компании.
Организовывали раз в неделю кружок и рассказывали кто с какой новой технологией поработал или же что-то нового узнал, что может быть полезно в работе над проектом.
Была доска почета, где друг другу выдавали звезды за выполнение каких-то тяжелых заданий, за элегантные идеи или же за что-то еще, что очень понравилось члену команды. По результатам недели или спринта выдавали милую фигню, кто набрал больше «лайков». В целом все было честно, манипуляций не было.
Прочитав пост от девушки и этот, вспомнил свой путь, как нанимали студентом, и как сейчас тоже собеседую порой, и как друзья ходят на собеседования, и как сам ходил недавно.
Считаю, что спецов надо драть в хвост и гриву скорее всего и смотреть на их участие в сайд-проектах (личные или опенсорс), так как тут вопрос о том, чтобы наносить пользу как можно скорее, и их знания должны быть актуальны и полны.
К начинающим же несколько мягче надо быть, так как объем знаний по отрасли только возрастает, а старые технологии не так быстро умирают. Т.е. нынешним новичкам в какой-то мере тяжелее втянутся чем нам когда-то. Касательно безопасности: системы становятся более защищенными и за время эволюции конкретных программ, искать в них уязвимости все сложнее и все больше квалификации надо.
Образ и ход мыслей тоже трансформируется соответственно профессии со временем, но в новичках наверно главное базовые знания (реально базовые, а не то что профи включает в это понятие) и жгучее желание работать в выбранной сфере, а не попробовать.
Все справедливо, если компания может себе позволить набирать реальную зелень.
Если смотреть бесчисленные видеокурсы и читать статьи, то будет «синяя рожа» и никакой радости жизни )) в молодости должна быть радость жизни.
Хорошее начало!
Можно далее рассказать об основной проблеме при использовании CQRS + Event Sourcing: Как строить AR и как решать проблему взаимодействия между разными AR.
Рассказчиком был Сергей Орлик и это была компиляция его предыдущих рассказов об архитектуре. Слайды доступны по адресу www.slideshare.net/sorlik/presentations
Вы указали слои: Бизнес архитектура, Архитектура информационных систем (потоки данных), Технологическая архитектура
Соответствуют они EA, SA, IA или нет?
Первые два слоя для EA, третий для SA. IA работает на всех уровнях скорее всего (второй и третий сильнее акцентируются). Слои в данном случае скорее относятся к логической части систем. IA занимается физической частью.
Далее по фото: я не готовил этот доклад, так что не могу сказать что на фото противоречит друг другу. Я так понимаю, что EA первый среди равных и он должен быть в курсе всех аспектов.
Топология развертывания систем и их компонент, Топология сети и подключения оборудования, Физическое размещение систем — EA должен знать примерно как оно выглядит и активно работать с IA чтобы прояснить детали. Самому такой объем оперативной информации в голове держать очень тяжело я думаю.
Полный список задач предоставить не могу, у меня его нет. Хотя можно попробовать достать презентацию.
В оригинале, в вики было слово transition. Тогда перевод может быть как «перевести\отобразить», исходя из контекста. Я использовал «перевести» в смысле отобразить в программных комплексах, перевести в цифру.
Предполагаю что нам программистам, легче воспринимать мир таким какой он есть. Прежде всего потому, что благодаря высокой степени аналитических составляющих нашего мышления — мы в состоянии пробиваться через барьеры информационного шума и видеть вещи в их истинном обличии.
Многие знания — многие печали. Так что может быть мир легче видеть как есть, но восприятие от этого не упрощается.
Но эмоций становится меньше, что есть то есть.
Профессор логики не плакал на похоронах утонувшего друга. Друг не умел плавать, поэтому и утонул. Логично.
По поводу эмоционального запоминания, я читал, что люди накапливают эмоции и одна большая радость может не перевесит кучу мелких и будничных проблем. Вполне может быть так, что утром будильник поставил на полчаса раньше, чай закончился, шнурок порвался, в любимой ручке закончилась паста, любимый автор не постит уже 5 дней ничего — день испорчен. И внезапно выигрываешь в лотерею 500К, например. Но день все равно уже испорчен и в полный рост нет радости.
Конечно себя надо отучивать от этого. Хотя похожее поведение замечал за товарищами.
Так что насчет пикового качества можно поспорить. Тут скорее играет фактор последней эмоции для какого-то события, которая ретуширует все событие в нужном свете. А?
Насчет делегирования ответ получен и засчитан =) Считаем, что работа делегировалась такая, которую мы сами можем оценить или сделать. А если у меня нет достаточной экспертизы в делегируемом вопросе?
Напоминает тезис о том, что все достигают своего уровня некомпетентности ;)
В некоторых компаниях понимают, что надо вести 2 карьерных лестницы: управленческая и техническая. Это к вопросу 1.
И если есть 2 лестницы, то технические вызовы только порадуют спеца. Это к вопросу 2.
Но я знаю о двух лестницах только в крупных зарубежных компаниях, которые работают на нашем рынке.
Интересная мысль, но после прочтения я вспомнил о популярном наблюдении, что собственный код через полгода кажется «индусским». Так вот о качестве, на мой взгляд, можно говорить в таком же ключе, мы можем оперировать своим представлением о качестве исходя из своих возможностей и способностей, которые применяем к другим. Как тогда оценивать делегрованную работу, если ее исполнитель не столь компетентен в нужной сфере. Понятно что надо учить, но чтобы его работа стала качественной по собственным меркам — доделывать самому? А если не доделывать, то надо смириться с «некачественным» продуктом?
Да, приведенный пример доводит абстрактную ситуацию до некоторого крайнего рубежа. В жизни слишком много компромиссов. Но тем не менее, как быть?
К тому же такое поведение становится выгодно, когда большая часть игроков так же придерживается данного мнения и плюшки получают люди которые делают быстро и качественно. Но возвращаясь к жизни, на людях с очень высокими планками качества удобно ехать не платя. Так как всегда можно потыкать носом в проваленные сроки, за это не повышать зп, а человек будет делать все так же качественно и даже лучше. Но дольше. Надо просто сокращать сроки разработок, чтобы сохранять кнут.
Это ведь real-world case
В Lokad, как я вижу, версия используется для снэпшота, чтобы определить к какому снэпшоту применять/восстанавливать события, так?
Но ведь и сами события могут изменятся в процессе разработки, а стек событий уже может быть в базе и при большом восстановлении с нуля, возникает проблема конвертации.
Хочется больше информации на этот счет с примерами. Так как теоретического материала много, но как-то это вскользь все рассматривается.
Вопрос снимается.
финальный билд ReSharper, VS12 RC 11.0.50706.0
до этого регулярно ставил nightly build
система Win7 x64
В других старался привнести похожие вещи и в целом удавалось, возраст был примерно тоже в районе 25.
Традиции были такие:
Настольные игры после обеда. За полчаса можно было сыграть партию. Так же были настольные игры по пятницам. Очень помогало сплотить коллектив и лояльнее относишься ко всем коллегам.
В той же компании летом собирались по выходным, пекли печеньки и опять же играли в настолки.
В конце релизов были походы в рестораны от компании.
Организовывали раз в неделю кружок и рассказывали кто с какой новой технологией поработал или же что-то нового узнал, что может быть полезно в работе над проектом.
Была доска почета, где друг другу выдавали звезды за выполнение каких-то тяжелых заданий, за элегантные идеи или же за что-то еще, что очень понравилось члену команды. По результатам недели или спринта выдавали милую фигню, кто набрал больше «лайков». В целом все было честно, манипуляций не было.
Считаю, что спецов надо драть в хвост и гриву скорее всего и смотреть на их участие в сайд-проектах (личные или опенсорс), так как тут вопрос о том, чтобы наносить пользу как можно скорее, и их знания должны быть актуальны и полны.
К начинающим же несколько мягче надо быть, так как объем знаний по отрасли только возрастает, а старые технологии не так быстро умирают. Т.е. нынешним новичкам в какой-то мере тяжелее втянутся чем нам когда-то. Касательно безопасности: системы становятся более защищенными и за время эволюции конкретных программ, искать в них уязвимости все сложнее и все больше квалификации надо.
Образ и ход мыслей тоже трансформируется соответственно профессии со временем, но в новичках наверно главное базовые знания (реально базовые, а не то что профи включает в это понятие) и жгучее желание работать в выбранной сфере, а не попробовать.
Все справедливо, если компания может себе позволить набирать реальную зелень.
Если смотреть бесчисленные видеокурсы и читать статьи, то будет «синяя рожа» и никакой радости жизни )) в молодости должна быть радость жизни.
Весьма интересно будет почитать и чтобы достаточно подробно касательно технических моментов.
Можно далее рассказать об основной проблеме при использовании CQRS + Event Sourcing: Как строить AR и как решать проблему взаимодействия между разными AR.
Первые два слоя для EA, третий для SA. IA работает на всех уровнях скорее всего (второй и третий сильнее акцентируются). Слои в данном случае скорее относятся к логической части систем. IA занимается физической частью.
Далее по фото: я не готовил этот доклад, так что не могу сказать что на фото противоречит друг другу. Я так понимаю, что EA первый среди равных и он должен быть в курсе всех аспектов.
Топология развертывания систем и их компонент, Топология сети и подключения оборудования, Физическое размещение систем — EA должен знать примерно как оно выглядит и активно работать с IA чтобы прояснить детали. Самому такой объем оперативной информации в голове держать очень тяжело я думаю.
Полный список задач предоставить не могу, у меня его нет. Хотя можно попробовать достать презентацию.
Многие знания — многие печали. Так что может быть мир легче видеть как есть, но восприятие от этого не упрощается.
Но эмоций становится меньше, что есть то есть.
Профессор логики не плакал на похоронах утонувшего друга. Друг не умел плавать, поэтому и утонул. Логично.
По поводу эмоционального запоминания, я читал, что люди накапливают эмоции и одна большая радость может не перевесит кучу мелких и будничных проблем. Вполне может быть так, что утром будильник поставил на полчаса раньше, чай закончился, шнурок порвался, в любимой ручке закончилась паста, любимый автор не постит уже 5 дней ничего — день испорчен. И внезапно выигрываешь в лотерею 500К, например. Но день все равно уже испорчен и в полный рост нет радости.
Конечно себя надо отучивать от этого. Хотя похожее поведение замечал за товарищами.
Так что насчет пикового качества можно поспорить. Тут скорее играет фактор последней эмоции для какого-то события, которая ретуширует все событие в нужном свете. А?
Насчет делегирования ответ получен и засчитан =) Считаем, что работа делегировалась такая, которую мы сами можем оценить или сделать. А если у меня нет достаточной экспертизы в делегируемом вопросе?
В некоторых компаниях понимают, что надо вести 2 карьерных лестницы: управленческая и техническая. Это к вопросу 1.
И если есть 2 лестницы, то технические вызовы только порадуют спеца. Это к вопросу 2.
Но я знаю о двух лестницах только в крупных зарубежных компаниях, которые работают на нашем рынке.
Да, приведенный пример доводит абстрактную ситуацию до некоторого крайнего рубежа. В жизни слишком много компромиссов. Но тем не менее, как быть?
К тому же такое поведение становится выгодно, когда большая часть игроков так же придерживается данного мнения и плюшки получают люди которые делают быстро и качественно. Но возвращаясь к жизни, на людях с очень высокими планками качества удобно ехать не платя. Так как всегда можно потыкать носом в проваленные сроки, за это не повышать зп, а человек будет делать все так же качественно и даже лучше. Но дольше. Надо просто сокращать сроки разработок, чтобы сохранять кнут.
И мы плавно переходим к теме о треугольнике «Скорость — Качество — Цена» ;)