среда, 30 ноября 2016 г.

Мотиваторы, возраст, Ё

Очень важно в процессе обучения постоянно находить для себя какие-нибудь мотивирующие вещи. Например, вчера это был разговор с кам-то из сокурсников о том, как это здорово - стать программистом и как поскорее бы хотелось уже устроиться на новую работу. Сегодня это может быть чья-то статья, в которой рассказывается о том, что учиться никогда не поздно. Завтра - новая вакансия на LinkedIn, для которой тебе не хватает изучить всего-то ничего (какие-нибудь Spring's или Hibernate). Послезавтра - новый подкаст на IT-тему. Еще дальше - видео на Youtube про switche-ров и все такое.
Все эти вещи будут являться теми самыми "хлебными крошками", которые покажут тебе, что ты идешь в правильном направлении.

Замотивировавшись сегодня "по самое небалуй" вечером "ухну" следующее задание по Exception-нам.))

Про возраст. Я уже вроде бы раньше писал, что возраст - учебе не помеха. Хочу выложить здесь свои более структурированные мысли на эту тему.
Для сомневающихся, переучиваться или нет, есть еще один способ решения "проблемы" возраста. Это арифметический способ: 
Допустим, например, что возраст "сомневающегося" составляет 40 лет. Сколько из них он работает по своей последней специальности? Самый максимум - 20 лет без высшего образования и 18 лет - с высшим.
Сколько лет ему осталось работать до официальной пенсии? 20 лет. А обещают, что скоро это будет 23 года.
Таким образом, в возрасте 40 лет человеку предстоит работать дольше, чем он уже отработал до этого. Т.е. трудовая деятельность его еще не закончилась даже наполовину.
Если такой человек задумался о смене профессии и единственное, что его смущает, это вопрос о том, а не поздно ли он все это затеял, то после приведенных расчетов вопрос можно изложить в таком виде:
- сможешь ли ты продолжать дальше работать в той же специальности, что сейчас, еще 20 лет или лучше попробовать что-то другое?

Про "Ё". С недавних пор я настроил на клавиатуре на букву "Ё" переключение языка ввода. В Windows на работе это оказался единственно возможный способ сделать переключение языка ввода не alt+Shift  и не Ctrl+Shift. Устанавливать специальные программы для этого не захотел (зачем замусоривать систему). Зачем мне понадобилось изменять сочетание клавиш для переключения языка? Все просто: дома я работаю на Ubuntu в IntelliJ IDEA. В ней использую сочетание клавиш Ctrl+Shift+/ для комментирования строк. Одновременно при этом переключался язык ввода. Пришлось сменить сочетание клавиш на другое и дома и на работе, чтобы все было "безобразно, но однообразно" ))


До        После        GitHub        LinkedIn

понедельник, 28 ноября 2016 г.

Switche-боязнь

Уже довольно давно меня мучает вопрос о том, почему java-исты так боятся оператора switch().
Вот, написал я вчера программу. В ней указал:
String key = input.ask("Enter your choice number: ");
switch (key) {
    case "0":
    case "1":
    case "2":
    case "3":
    case "4": menu.choice(Integer.parseInt(key));
         break;
     case "5": return;
     default: System.out.println("Incorrect input. Try again.");
}
Ментор сказал, что всё отлично, вот только switch() надо убрать. Конечно, ранее он говорил о том, что якобы switch() - это усложнение чтения программы и надо его везде заменять на if-else(), но я почему-то думал, что это относится к случаям, когда после каждого case: пишут по несколько строк кода.
В моём же случае всё очень наглядно и легко читаемо. Отсюда и вопрос: почему java-исты так боятся оператора switch()?
Вот, сейчас поменяю это на if-else() и получится непойми что. Ну, да, ментору наверное виднее. ))


До        После        GitHub        LinkedIn

суббота, 26 ноября 2016 г.

"Программисты" vs "инженеры"

На днях в одном из подкастов услышал очередное "откровение" о том, что есть два подхода к разработке ПО:
1\ инженерный подход - если работает, то лучше это не трогать;
2\ подход программиста 80 лвл - всегда всё переделывать.

При этом ведущие были явно на стороне второго подхода. И вроде обосновывали это красиво, и я даже местами был с ними согласен... Но, блин, как же я понимаю "инженеров"... ))


До        После        GitHub        LinkedIn

пятница, 25 ноября 2016 г.

Куча новостей

Привет, привет, привет!
Давненько не писал ничего. Учёба набирает обороты и совсем нет времени заниматься графоманией. Да, что там блог, не хватает времени даже на то, чтобы выспаться как следует. Учусь ежедневно до 01:00 - 02:00 AM .
Программы пишу - только клавиши на клавиатуре летят.
На курсе изучения Java каждую неделю происходят какие-то глобальные изменения. То maven нужно подключать к проекту, то checkstyle, то cobertura, то из sublimetext нужно перебираться на IntelliJ IDEA. Инструкции по всем этим инструментам приходится искать в интернетах и как-то адаптировать их под свои проекты. А после этого - ещё и ранее написанный код исправлять и комментировать.
В общем, всё как в самых "взрослых" "полевых условиях". Cложно, но очень интересно. ))

Из новостей:

1\ Наконец-то меня избавили от этого глючного skype! Недавно всё общение между обучающимися на курсе перенесли из skype в Hipchat (интересно, название образовано от слова "хиппи" или "хипстер"?)) Теперь по каждой учебной теме есть отдельная "комната" для общения, стало меньше флуда и теперь легче находить нужную информацию и задавать вопросы о наболевшем.
А наболевшего - просто горы. Пётр (руководитель курса) любит давать загадочные задания. ))
Такие, на пару-тройку часов погуглить. Да еще и по англоязычным сайтам.

2\ Skype заблокировал свежесозданный аккаунт моей жены, т.к. не нашел у себя в базах привязки акка к конкретному лицу (она у меня та ещё конспираторша). Написали, что аккаунт "подозрительно активный" (ага, общалась всего месяц только со мной и по 1 фразе в 2-3 дня) и потребовали ввести свой номер телефона, чтобы, значит, снять все подозрения. )))
Что у всех за навязчивая идея такая: во что бы то ни стало установить, какому реальному человеку принадлежит аккаунт?..

3\ В грядущем году планирую пойти в отпуск зимой или в начале весны, чтобы меня не отвлекали от учёбы поездками на дачу или пляж. Надеюсь, что смогу за 4 недели отпуска освоить очень большую часть курса. Ведь в следующем году уже нужно искать новую работу (план у меня такой).

4\ На LinkedIn изменил свой профиль с "адвокатского" на "программерский". Сразу увеличилось количество просмотров профиля, количество интересных вакансий и вообще теперь всё просто здорово! ))

5\ Роскомнадзор заблокировал LinkedIn и кто-то ушлый уже через пару дней его "импортозаместил". Этот "заместитель" - это просто смешно. Судя по описанию, может быть ЛинкЮ и станет популярным среди той прослойки населения, для которой очень важно, какой ты рассы, вероисповедания и, какой у тебя любимый питомец. Т.е. среди тех, кто сейчас активно обитает в одноклассниках, вконтактиках и прочих своих мир@мэйлах.
Мне на такое "замещение" даже посмотреть не захотелось. Мы, профессионалы, остаемся на LinkedIn, т.к. умеем преодолевать административные барьеры. ))

6\ Поисковые сервисы хором "зажали" результаты поиска по запросу "расширение chrome для доступа к luinkedin". В первый день блокировки в любом поисковике можно было найти минимум 2-3 расширения в первых же строчках результатов.
Через два дня - уже нет.

7\ Вчера на рабочий комп хотел поставить программулину, скачанную из "недоверенного источника". Вместо программы установилось столько малвари от мэйл.ру, сколько до этого я не видел одновременно в одно время и в одном месте. Потратил пару часов на то, чтобы вычистить её ото всюду. Они что себе думают, что я после такого хамства стану их преданным пользователем?

8\ Наш Президент наехал на "учёных" - чиновников, которые для получения большей з/п "пролазят" в Российскую Академию Наук. Видел этот сюжет краем глаза по ТВ. Больше всего поразила реакция главного "академика" на вопрос Президента о том, действительно ли все эти чинуши являются "видными учёными", без которых наука "зачахнет". Этот самый главный "академик" ответил, что, они (чинуши), дескать, сказали, что начальство им разрешило стать академиками.
Мне моё начальство тоже разрешило стать академиком. Только при чём тут наука? ))

9\ Ежедневно пополняю свой репозиторий на GitHub новыми учебными программами.


До        После        GitHub        LinkedIn


понедельник, 14 ноября 2016 г.

Не сдаёмся

На курсе по Java уже больше 100 учеников. 
Второй модуль курса порадовал очередным "сюрпризом" - нужно было создать UML диаграмму классов для системы учёта заявок пользователя. при этом пользователю должно выводиться меню и предлагаться выбрать возможные действия с заявками (создать, изменить, удалить и т.д.). В UML диаграмме должны быть расписаны какие у классов должны быть методы, их параметры и что они будут делать.
Ну, что тут можно сказать, после первой лекции посвящённой наследованию и ничему больше... Что такое UML? Понятно, изучаем самостоятельно. На что должны быть заявки? Заявки каких видов могут быть? Зачем системе учёта заявок самой выводить пользователю какое-то меню и как-то обрабатывать введенные пользователем данные?

Пару дней потратив на изучение UML и принципов построения диаграмм, наваял нечто несуразное в таком духе:
Блок-схема
UML-диаграмма классов
От недостатка исходных данных получилось непонятно что. Преподаватель курса тоже ничего не понял и попросил расписать класс Tracker в словами в виде текста. ))
В виде текста получилось сделать что-то более-менее похожее на план программы.
После этого ещё день смотрел на youtube лекции по ООП, читал книжку по Java и писал конспеты.
Надо будет потренироваться с написанием родительских и дочерних классов, чтоб не забыть пройденный материал.

По сложившейся у меня дурной традиции, английским и спортом на выходных не занимался, т.к. все силы бросил на Java и UML. Новых программ за выходные тоже не написал.

До        После        GitHub

понедельник, 7 ноября 2016 г.

Первый экзамен

Вчера состоялся мой первый экзамен на курсе Петра Арсентьева "Программирование на Java".
Пётр ошибочно полагал, что до Java я изучал программирование  на Паскале. Поэтому все его вопросы были направлены в основном на отличия между Java и Паскалем (например, про динамические и статические массивы). Я же Паскаль видел только краем глаза, да и то издалека, и до Java изучал C. Поэтому не сразу понимал, что от меня хочет услышать Пётр, отвечал сбивчиво и задавал много уточняющих вопросов. Другими словами, "тупил". ))
Но, вроде как, сдал. Перешёл на второй модуль курса (а всего их 14). 

В скайп-чате среди студентов курса ходили слухи о том, что только один человек смог пройти весь курс за один год, все остальные застряли где-то посередине. Пётр говорил, что можно пройти весь курс за 8 месяцев. Значит, это и будет мой план на ближайший год - пройти весь курс и найти работу.

В качестве итогового задания по первому модулю курса Пётр попросил написать программу, которая объединяет два отсортированных массива в один, который также должен быть отсортирован.
Сначала я хотел сделать одновременную сортировку с объединением (т.е. брать по одному элементу из каждого source-массива (источника), сравнивать их и класть в destination-массив (результирующий). Но, по здравом размышлении, решил, что написать такой код сложнее, чем написать классу, копирующий 2 массива в один и прикрутить к нему имеющийся у меня класс-сортировщик (сортирует методом перестановки или, как ещё называют, "пузырьковым" методом).
Итоговый алгоритм получился таким:
1) копируем первый source-массив в destination-массив;
2) следом за ним копируем в destination-массив второй source-массив;
3) после этого сортируем destination-массив.

Получился код в духе Java-way и в ООП-стиле - из уже имеющихся классов создал новую программу. Написал только один новый класс Copier - для копирования двух массивов в третий. Ну, и, соответственно junit-тест писал только для класса Copier, т.к. тесты для всех остальных классов уже были написаны в другой программе.

На правах рекламы буду в каждом сообщении указывать ссылку на свой GitHub.
В ближайшее время добавлю на GitHub в chapter_001 ещё 2 программы из первого модуля и создам новый каталог chapter_002 для программ второго модуля.

До        После

среда, 2 ноября 2016 г.

00:00 - developing

Уже второй день подряд к 00:00 часам заканчиваю писать программы. Если  и дальше так продолжится, то пора будет вводить новый термин, обозначающий стиль такой разработки: 00:00 - developing. ))

Где-то на GitHab будут лежать все мои "две" учебные программы. ))

Что интересного заметил в курсе программирования на Java:

1. Задания на "закрепление" теоретического материала на несколько тем опережают сам пройденный материал.
Что в этом может быть хорошего: традиционно считается, что наиболее эффективное обучение - это когда сам ищешь ответы на вопросы.
Что в этом может быть плохого: тратится очень много времени на поиск нужной информации; найденные ответы не всегда являются правильными; теряется системность обучения.
Самостоятельное обучение проходит в духе: а давайте нажмём вот на эту кнопку и посмотрим, что из этого получится. ))
При выполнении "опережающих" заданий приходится использовать отдельные вещи без чёткого понимания того, что они делают и как они должны это делать.

2. Junit-тесты отнимают времени не меньше, чем написание самой программы. Вот она, программа. Она работает и возвращает корректные значения. А тест не компилируется, а если компилируется, то фэйлится. )) Приходится "ковырять" сам тест и заставлять теперь уже его работать.

Странным мне представляется подход к написанию программ, при котором для программы сначала пишется Junit-тест, а потом уже код, который этот тест должен проверить. Это похоже на поэтапное написание класса с методом main()
Так как я пока не могу сходу написать программу или тест без ошибок, то одновременное написание программы и теста для неё усложняет написание программы, т.к. приходится придумывать "заглушки" для кода, увеличивает в 2 раза количество ошибок и сильно усложняет их поиск.
Поэтому я пока что пишу тесты к программе в таком порядке: сначала пишу программу и класс с методом main() и отлаживаю её, а потом уже на основе кода из метода main() делаю тесты к работающей программе.

Эх, поскорее бы пройти начальные модули курса и приступить к более серьёзным вещам, чем расчёт площади треугольника. ))

До        После

вторник, 1 ноября 2016 г.

Очередной выверт мозгов

Java  в очередной раз выворачивает мне мозг.
Вчера весь вечер вникал в приведённый на курсе Петра кусок из программы для расчёта площади треугольника. В конце-концов, как это работает я разобрался. Только не понял, зачем было так всё усложнять:
1\ есть класс "точка" с координатами (х, у):
- в этом классе указывается, что: this.x = x, а this.y = y: (надо, кстати разобраться с этими this. , а то что-то везде их пишут, а что это - не рассказывают),
- в этом же классе пишется метод, рассчитывающий длину стороны по формуле Герона;
- этот метод принимает в качестве параметра второй объект-"точку" с координатами (x, y).
2\ далее, есть класс, в котором будет вызываться метод расчёта длины стороны из одного объекта-точки и передавать ему в качестве аргумента второй объект-точку;
3\ создаются два объекта-точки: точка-А и точка-Б;
4\ создается метод, который будет вызывать метод расчёта из объекта точка-А и передавать ему в качестве аргумента объект точка-Б...

Пётр пишет, что это правильный код в духе ООП, метод расчёта длины стороны в нём более лаконичен и т.д. Как это работает, я разобрался. Но не понял, для чего нужно было всё так усложнять? Почему нельзя было сделать проще: в один метод расчёта длины стороны передавать в качестве аргументов координаты двух точек? Такой метод можно вызвать столько раз, сколько точек вершин у фигуры, а в качестве аргументов можно передавать ему массив с координатами точек.
Зачем было городить такой "огород" из объектов? Ладно, в задаче всего 3 точки, а если их будет 6, 12 или 24? Никак не могу понять, в чём тут выгода по сравнению с одним методом... Точки и их координаты постоянно "летают" от одного объекта в другой. Очень сложно отследить их "траекторию".

Сегодня попробую написать эту программу сам, без подглядывания в код Петра, и проверить её работоспособность.

До        После