Search
Write a publication
Pull to refresh
7
0
ItGold @ItGold

User

Send message
Если говорить про техническую линию, то скорее всего это будет развитие именно в сторону дизайна, проектирования, архитектуры. Менеджеры и аналитики это уже несколько другая степь и впринципе можно становиться сразу менеджером или аналитиком, без какого-либо технического опыта. Правда не желательно.
Эк как вы меня в сторонники Соло окрестили быстро. На самом деле я не слишком увлечен темой данной беседы, дабы приписывать себя к сторонникам или противникам. Прошел соло в свое время и больше о нем не вспоминаю. Всякие стамины и др. мне показались более скучными.
На вопрос Ваш отвечать я не могу, как Вы уже и метко намекнули, мой поинт был не в этом. А в том, что пройдя курс вы бы могли рассуждать о том, хороший он или плохой, замерять свои собственные показатели в начале и в конце, а затем предоставлять нам разницу в своих результатах и делать соответствующие выводы. Но так как этого не произошло, вывод можно сделать только о том, что Вам эта прога не пошла. А т.к. существуют другие товарищи, которые все же прошли курс, нельзя отрицать тот факт, что некоторым все же соло пошло на пользу, и основная цель была достигнута. Не люблю критику там, где для нее нету достаточно веских оснований. Если бы вы оформили пост в стиле «Какие улучшения я бы хотел видеть в курсе Соло», это было бы наверное более полезно.
Не понятно, что автор пытается доказать… Людей, которые завершили начатое дело всегда меньше тех, которые бросили на пол пути. Если бы автор прошел этот курс до конца и потом, основываясь на своем опыте, сообщил нам, что он не работает, это было бы действительно стоящее заявление. Но так как этого очевидно не произошло… wtf? Некоторым нравятся одни способы обучения, некоторым — другие. Автору соло не попер, и это не значит, что он больше никому не прокатит.
Молодец, правильное замечание. Но не настолько, чтобы называть книгу крайне неудачной. В конце концов время расставит все на свои места и человек начинает понимать, что эти т.н. «патерны» несколько низкоуровневые и не совсем похожи на те, что в GoF. Кстати, кое-что из GoF там тоже имеется. Кроме того Ларман описывает не только эти т.н. принципы но и дает примеры анализа и проектирования соответственно и в очень неплохой форме. Вцелом из нее можно много чего почерпнуть.
А Head-First это вообще нечто. Практически вся серия это ацкий отжег. К сожалению Design Patterns вот расписаны не в полном составе, но те, что есть, просто на 5 баллов.
За исключением пунктов 2 и 6 впринципе советы нормальные. Можно брать на вооружение.
Блин, погодите! Неужели никто не замечает такую странную вещь, что кто-то методично втирает котам, что их счастье в хвосте? Почему именно в хвосте, а не, допустим, на носу или за ухом? И что самое удивительное, почему коты так легко ведутся на эту дурку? Чудеса да и только…
Полного дегенерата обучать жаве не только бесполезно, но и экономически нецелесообразно. Даже студентов последних курсов на работу берут только в том случае, если в компании уже есть сработаный коллектив зубров, которых разбавляют джуниорами, чтобы сократить расходы. Если человек оказывается дегенератом, он обычно надолго не задерживается. Так вот, выбор контейнера не такая уж непосильная задача, с которой можно справиться только протерев с десяток штанов за партой. Сложность алгоритма? Навык оценивать задачу и предлагать гибкое, решение, удовлетворяющее требованиям, приходит только с практическим опытом + самообразование. Сколько новоиспеченных молодых специалистов, могут оценить сложности алгоритма налево и направо? Следуя Вашей логике — все. На практике все происходит иначе.
Тем более, могла бы такая мама обеспечить сыну хорошее образование. Это наверное основное, о чем думают родители, когда приходит время. Сомневаюсь, что мамы в совете дирректоров IBM потакают сыновьям прогулы в школе.
1. Обычно читают именно то, что востребовано на рынке и что интересно читающему. А не то, что какой-то дядя, далекий от программизма, навязывает в качестве обязательной программы.
2. Со вторым не поспоришь. Лучше его иметь чем не иметь.
3. Он начинал программистом, потом стал архитектором ну и потом уже скатился в бизнесмены.
Как Вы резко, сказал как отрезал.
А что делать тем, кому просто нравится программирование? Кто готов развиваться самостоятельно и зачитывается многотомными трудами бородатых дяденек? Вы хотите сказать, что люди, у которых нету вообще математического образования не способны ни на что в программировании? Билл Гейтс получил высшее образование совсем недавно. Лэрри Эллисон, основатель оракл, тоже забил. Уверен, что существует еще масса примеров, которые не столь популярны, но добились очень многого. Ну право слово — быдлокодеры, куда им до нас, математиков?!
Ну в целом я с вами согласен. Если это поможет уточнить задачу, или понять что-то -всегда пожалуйста. Главное, не создавать нескольких источников для такой информации, чтобы не приходилось после баг-трекера еще и в логи vcs лезть. Если что-то можно сказать по поводу данного конкретного коммита, то конечно пусть будет коммент, не повредит так точно.
Ай фу, какая гадость! Как туда попало столько лобковых волос???
У нас используется Hudson в качестве build-системы, Jira — баг трекер и Svn. В комментариях к комиту указываем номер бага, по которому произошел комит, ну и может пару слов, если есть чего добавить. Никаких соплей и размазни, если это уже описано в баге и не сделано никакой дополнительной работы, таким макаром у нас не получается никакого дублирования того, что уже описано баг трекере. Hudson, во время билда проверяет комменты и в случае совпадения номера бага в Jira постит туда коммент — «По этому багу были зачекинены файлы такие-то» со ссылками на соответствующие ревизии файлов в svn. Очень рекоммендую.
2Г-н smira, вы не обижайтесь, но похоже как руководитель разработки вы очень занудный товарищ.
Вообще то более распространенное название «выгорание». Да и burnout так переводится.
Ну вот теперь и здесь скоро все будет спамом завалено…
Народ, это только мне iTunes поперек горла встал? Или это на самом деле хорошая софтина, которой можно пользоваться?
Учиться на плохихи примерах тому, как проектировать систему не есть хорошо, и тем более приводить подобные примеры в качестве показательных.
Использование String в качестве хранилища данных очень похоже на оперирование объектами Object. Впринципе нас окружает куча объектов и по сути Ключ тоже объект. Но суть грамотного проектирования в том, чтобы остановиться на каком то логическом уровне абстракции, позволяющем расширение свойств объекта, и в то же время недопускающем наделение объекта свойствами, ему не присущими. Поэтому, допустим в примере с ключом, автор не выделил например интерфейс ХреньВКармане или ВтыкательВоЧтоТо. А ограничился простым интерфейсом - Ключ.
Уважаемый, скажу вам по секрету, что абстрактный класс тоже может имплементить интерфейс! Никто не говорит, что абстрактные классы зло, просто в данном конкретном случае он неуместен. Объясню: интерфейс Ключ не может быть абстрактным, потому что природа открытия двери в его реализациях полностью различна. В одном случае метод +open() использует механизм открытия путем поворота самого ключа, в другом, используя карто-приемник. Вопрос - какую имплементацию вы хотите засунуть в интерфейс Ключ, сделав его абстрактным классом?
Если у нас будет несколько имплементаций ключей одного типа(например ключ с секретом, который нужно надавить как-нибудь, прежде чем поворачивать и обычный ключ) имело бы смысл заимплементить интерфейс Ключ в абстрактном классе КлючПоворотный и заэкстендить этот класс в классах ОбычныйКлюч и КлючССекретом.
Автору - респект! Отлично описал, но до некоторых все равно не доходит.
- имена пакетов всегда пишутся маленькими буквами.
- геттеры getBusDAO и подобные с capital case в названиях полей выглядят убого и не соответствуют Java naming conventions.
Простите, а Вы что, динозавр?

Information

Rating
Does not participate
Date of birth
Registered
Activity