Если нельзя, но очень хочется, то нужно обязательно и ничего в мире не стоит того, чтобы делать из этого проблему!


Интересна Java? Кликай по ссылке и изучай!
Если тебе полезно что-то из того, чем я делюсь в своем блоге - можешь поделиться своими деньгами со мной.
с пожеланием
столько времени читатели провели на блоге - 
сейчас онлайн - 

пятница, 24 апреля 2015 г.

OpenSource для тренеров

В последнее время много приходится общаться не тему "а разработайте нам java курс" с плавно переходящим в сторону "а так чтобы у нас все права были на него". 


И я так и делал много раз, пока не увидел систему. Система вот в чем. Всем нужно одно и то же. И если для каждого делать свою копию, то времени уйдет очень много. У меня есть курс Java уже в трех компаниях. Они ими пользуются и я рад, что ребята получают от этого пользу. Еще 5 запросов пришлось отклонить по той простой причине, что я сейчас занят адаптацией курса в GoIT. 

И вот на одном из собраний Остапа в очередной раз понесло и родилась идея. А что если перестать думать, что программа это святая святых и просто 5-10% бизнеса, наличие которого не гарантирует успех компании, но дает ей возможность стартовать. Что если программа всегда будет в открытом доступе, и любой желающий сможет ее исправить/дополнить или просто взять и использовать на свое усмотрение. В Java мире царит opensource, так почему же программы обучения в миру Java так же не могут быть opensource?


Что входит в остальные 90-95% успеха компании? Слаженая команда из идейных людей. Хорошо построенный маркетинг и отдел продаж. Налаженная система и коммуникации. Управляющий, фултайм увлеченный развитием компании. Тренер (если мы про тренерский бизнесс говорим), который проведет по материалам первоклассный тренинг. Без этого всего - тренинг материалы, это просто груда тренерского металлолома. И ничего больше.  

С какими проблемами можно столкнуться, если, скажем, взять 1 тренера и попросить его создать программу для компании, чтобы обкатал ее на нескольких группах, а потом взять у него эксклюзивные права и отпустить с миром. Программа еще некоторое время просуществует и потом наверняка морально устареет так как все в мире IT очень быстро бежит вперед. Хорошо, наймем нового тренера - пусть обновляет. 

Скорее всего новый Тренер будет несогласен с мнением прошлого Автора и захочет "переписать все". Если бы Автор участвовал бы в этих переговорах, вероятно они с новым тренером нашли бы win-win решение или как минимум компромисс. Но Атора нет, программу обычно переделывает кто-то другой. И за это снова платит владелец (ну а эксклюзивные права кто запросил?) но уже другому человеку, потом третьему и так далее...


Скажу отдельно про "все херня". Часто слышу такие замечания. Потому что тот, кто делает что-то его всегда можно покритиковать. Особенно, если ты тоже успел сделать что-то. У меня бывали собеседования, на которых Автор мне прямо говорил "все херня - вот вам моя программа". И его можно понять. Ведь правило "все херня" расспостраняется и на мой и на твой и на его продукт. Это первая реакция. Но если так говорит автор, который сделал уже что-то - это его еще можно порасспрашивать и узнать много полезного и интереснного. Но если так говорит новичок в этом деле, я ему предлагаю законтрибьютить патч. Обычно на этом 90% "замечаний" отваливается.


Но вернемся к правам. Тут еще одна важная штука случается. Если попросить передать все права компании, то Автор теряет творческий интерес к программе, поскольку она уже не его. И со временем, когда с компанией дороги все больше расходятся - автор отваливается. Да у компании все права - но и головняк в виде программы с которой не понятно что дальше делать. 

И это все повторяется много раз подряд. Снова и снова. В разных компаниях. С одними и теми же тренерами. Пишут, отваливаются, другие дописывают, снова отваливаются. Вот бы пререзнакомить всех тренеров и пусть напишут одну программу, которую использовали бы все, каждый в своем контексте-бизнессе. И вот опять тот же самый opensource. Комьюнити driven подход.


Программа - это не просто листочек A4 с описанием тем, которые будут изучаться. В моем мире это все материалы и артефакты, которые может взять тренер и использовать в своих целях, дотачивая как ему удобно. Это: 1) презы в каком-то markup формате, 2) сценарии 3) сырцы проекта тестового 4) домашка 5) тексты мотивационные 6) линки на статьи и список литературы с рекомендациями 7) чеклисты 8) квизы 9) лайвхаки 10) рекомендации 11) описание форматов - весь арсенал материалов, которыми пользуется тренер в своем тренинге. 

Каждый модуль по какой-то теме, атомарный и независимый - бери и кушай. Развивай его если хочешь, котрибьють новые модуля - если хочешь. Все копилефт, используешь - все что заэкстендил должно так же бесплатно распостраняться. Чтобы больше небыло между тренерами разногласий. Чтобы они решались в коде. Ведь тренинг-программа это тоже код. Чтобы каждый желающий провести тренинг имел все, что надо для быстрого старта как он это обернет в свой маркетинг и сейлз - его задача. На этом он будет зарабатывать деньги, но материалы по тренингу будут при этом бесплатны и доступны всем.


Вот эту идею сейчас испытываю на прочность. Пока обсуждая с потенциальными клиентами: тренерами и учебными центрами. Но чуть позже, уже в следующем месяце, когда начну тренинг по JavaCore для Тестировщиков, собирающихся стать Автоматизаторами, я заведу git репозиторий и все материалы от модуля к модулю буду выкладывать туда. Посмотрим, что из этого получится. 

четверг, 23 апреля 2015 г.

Хочу войти, хочу выйти

Такая хорошая статья, что захотелось поделитсья ей тут. 

А еще вот на злобу дня :) Клип которй сделал мой день


Ну и много разговоров сегодня было на тему опенсорса. Мне почему-то вздумалось, что программа обучения по java должна быть в опенсорсе, как и все чему она учит. Программа открыта - все в нее контрибьютят кто хочет, а услуги на ее основе - тренинг там или что еще пусть уже будут платными.

Вот небольшой пруф на эту тему. 


Хорошего нам завтра!

вторник, 14 апреля 2015 г.

Spring IoC, Spring Security, Spring MVC тренинг

Елси ты начинающий разработчик. Если хочешь устроиться джавистом. Две строчки Spring + Hibernate в резюме придадут тебе уверенности. Но перед как их туда вписать тебе необходимо уметь Hibernate в applicationContext.xml вписать.

Мы с коллегой решили сделать кикстарт-тренинг для начала на тему Spring а потом и Hibernate. И по этой причине интересуемся насколько это сейчас тебе интересно.
Что это будет? Двухднвный интенсив тренинг со всеми плюшками от опытных тренеров. 
Темы Spring IoC, Spring Security, Spring MVC. Для старта тебе этого вполне достаточно. Дальше сам, ведь на тренинге мы поделимся не только знаниями но и навыками, которые сделают тебя более самостоятельным. 

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

Будет весело и продуктивно, так как мы работать будем в парах с элементами геймификации. Будет нетворкинг, так как мы ценим его как инвестицию в будущее. Будет суппорт тренеров после тренинга - вы попадете в нашу закрытую группу, где мы будем делиться всевозможными материалами по этой и другим интересующим тебя темам. 

Записывайся. За неделю все решится. Вот формочка для тебя

понедельник, 13 апреля 2015 г.

Как закоммитить разные части проекта в разные git репозитории?

Возникла задачка. Есть у меня основной проект, в корне которого как положено .git папочка скрытая c локальным репозиторием, .gitignore лежит - там прописано все то, чего я не хочу коммитить в основной репозиторий. Основной репозиторий закрыт и лежит на битбакете.

Есть небольшая часть проекта (исходники), которую я бы хотел открыть и выложить на публичном репозитории. Я не хочу заниматься никаким копипастерством этой части исходников в новый проект (с последующим его push в public repo), потому как это чревато провтыками с моей стороны. Я хочу чтобы у меня в одном проекте было два репозитория и я мог коммитить то в один то во второй легко и непринужденно.

Решений есть несколько, но начал я с велосипеда с квадратными колесами. Чуть ниже в комментариях есть дельные советы от отытных ребят, так что если тебе интересно правильное решение отправляю тебя сразу туда. Ну а если любишь квадратные колеса, тогда читаем дальше :)


Проект у меня многомодульный maven. Структура такая:
Codenjoy - корень, тут находится папка .git и файл .gitignore основного репозитория
Codenjoy\CodingDojo - тут находится родительский maven проект, сам он туп, только собирает все проекты в кучу
Codenjoy\CodingDojo\games - тут находятся все проекты-игры (их дофига)
Codenjoy\CodingDojo\games\engine - тут находятся общие для всех игр сырцы - именно их я хочу выложить в паблик
Codenjoy\CodingDojo\games\sample - тут находится пример, как создавать свою игру - это я тоже хочу зашарить.
Codenjoy\CodingDojo\games\game1 - это какая другая игра, которую я не хочу шарить
Codenjoy\CodingDojo\server - тут находится сервер игры, его я тоже не буду шарить

Итак, первая гипотеза заключается в том, чтобы сделать git init в папке Codenjoy\CodingDojo\games и я ее проверил. Более того IDEA даже подхватила его, и после добавления в качестве второго репозитория я даже сделал пару коммитов. Но потом git крешнулся. Как-то он закоммитил один файл в один репозиторий, а описание о коммите, в другой репозиторий. Потому пришлось все сносить и пробовать еще раз. Урок понял - два репозитория одновременно не прокатят, будем их переключать. Но как?

В папке Codenjoy\CodingDojo\games я создал два батника: disable-second-repo.bat
#disable-second-repo.bat
attrib -h .git
ren .git .git_
attrib +h .git_
ren .gitignore .gitignore_
cd..
cd..
attrib -h .git_
ren .git_ .git
attrib +h .git
и enable-second-repo.bat
#enable-second-repo.bat
attrib -h .git_
ren .git_ .git
attrib -h .git
ren .gitignore_ .gitignore
cd..
cd..
attrib -h .git
ren .git .git_
attrib +h .git_
И настроил .gitignore файлы во внутреннем репозитории
/game1/**
/engine/src/**
/engine/target/**
/engine/.idea/**
/engine/*.iml
/sample/target/**
/sample/.idea/**
/sample/*.iml
/*.bat
и внешнем (основном)
/CodingDojo/games/.gitignore
/CodingDojo/games/.gitignore_
/CodingDojo/games/.git
/CodingDojo/games/.git_
После добавил два репозитория в IDEA - на время пришлось включить оба. Потом отключил один (переименовав в .git_) и IDEA ругнулась, что один репозиторий отвалился. Ну ок, игнорим сообщение, жмем Ctrl-F5 на вьюшке Changes и видим то, что уходит на один репозиторий. Коммитим. А в git bash (который запущен из папки Codenjoy\CodingDojo\games) делаем git push. Все ушло! Переключаем репозитории одним из батников. Идем в IDEA. Жмем Ctrl-F5 на вьюшке Changes и видим то, что уходит на второй репозиторий. Коммитим. А в git bash (который запущен все из той же папки Codenjoy\CodingDojo\games) делаем git push. Все ушло! Только теперь в другой репозиторий. Profit.
Хоть и через Ж.
Вот, кстати, ради чего все старания.


А еще с днем меня рождения. Теперь буду байку рассказывать на тренингах, что ДР встретил за кодингом любимого проекта. А у тебя как ночь перед днем рождения обычно проходит? 

суббота, 11 апреля 2015 г.

FAQ по ведению блога

В последнее вроемя все как-то часто спрашивают про ведение личного блога. И первый вопрос надо ли вести блог? Айтишнику, мне думается, он нужен по ряду причин, которые я ранее озвучивал. Если тебя нет в гугле, значит тебя нет вообще. Блог это твой себе робот, который работает от твоего имени, пока ты делаешь что-то еще. Работа надо настроить. Робота надо кормить новыми программами. И он будет работать. Но перед тем надо понять, какими именно программами. 


На какую тему завести блог? А для начала можно просто создать блог в любом месте и просто туда начать постить все подряд. Где-то через пол года можно будет посмотреть его и сегментировать темы. То, о чем постил чаще всего - то и больше всего привлекает. А раз привлекает, значит стоит развивать направление. 

Что делать, если боишься поделиться своей мыслью с миром? Мало ли осудят, не так поймут или еще чего... Успокойся. Скорее всего первыми читателями твоего блога будут те, кто тебя знает лично и кому интересно то, что ты продуцируешь. Чуть потом к блогу гугл будет приводить и тех, кто гуглит что-то на ту тему, которую ты расскрыл у себя на страничках. Если им что-то не понравится, они закроют окно браузера секунд через 3 и даже глазом не моргнут - не так ли ты сам постуапешь когда надо быстро что-то нарисерчить? Если зацепит, останется с тобой до конца поста. Но в начале жизни блога (без привлечения траффика) скорее всего у тебя будет 0,5-2 читателя. Так что не переживай. Но что важно - все размещенное в сети никогда оттуда не удаляется. Потому делись тем, чем ты и так делишься уже но в устной форме. Тем, что по фидбеку слушателей - полезно. 


Что делать, если я не пишу граматна? Во-первых я тоже не литературный гуру. Но пишу и пишу много. Да есть очепятки. Я вообще мастер в них. Грубые очепятки - подскажет сам браузер. Остальное стоит подглядывать в книгах, когда их читаешь. Мне думается, что лучше написать пост, чтобы он смог помочь читателю (и пусть будет написан как написан), чем не написать его вообще (но литературно гениально). Перфекционизм выключаем. 


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


Как часто писать? Регулярно. Хочется или нет. Тема есть или нет. Надо сесть и заставить себя писать первых 5 минут. Потом уже оторваться не сможешь. Фрирайтинг подключится. Это сложно. Особенно когда в жизни все кишит-бурлит и времени нет. 


Где брать время на блог? Хорошо пишется утром, если проснуться на 1 час раньше обычного. Хорошо пишется после полуночи, когда все уже спят. Хорошо пишется на природе, когда никуда не надо спешить. Ну а если каждый день в погоне за чем-то, то стоит ходить с мыслью "а как я могу вот это вот, что сейчас делаю потом быстро в блог запостить" и идеи будут приходить. Например обсуждая что-то архиважное с кем-то в чате можно его потом скопипастить в блог, отформатировать и вот те классный текст. А если кому-то что-то лайвкодишь, можно записать и так же на ютьюб, а потом в блог. А можно и попросить кого-то набрать текст семинара, разбить на 3-4 поста и тоже в блог. Но если не задать себе вопрос "а как это запостить?" то скорее всего не приготовишься и потом выкладывать будет нечего. Ничего, будет еще возможность...


Как написать пост? Очень люблю MindMap. Штука, которая позволяет структурировать мысль. Вначале указываешь главную тему. Потом 7-10 основных вопросов, которые приходят в голову на эту тему. Потом по каждой из них пару идей как помочь ситуации. И вот у тебя уже готов скелет будущего поста. Теперь осталось озвучить это все в виде рассказа и набрать в редакторе.  Вот хороший пример

Как разукрашивать пост? Чисто текст сейчас малопривелкателен. Надо добавить рисунков каждых два три абзаца. Так же абзаци пусть будут не очень большими, иначе их сложно читать. В посте стоит выделить как-то основные ключевые вопросы или советы, чтобы пост можно было прочитать по-диагонали. В общем смотри в сеть - что тебе больше всего нравится читать, то на вооружение и бери. 


Ну и в конце-концов надо сделать какой-то призыв к действию! Заведи блог сегодня, и завтра в нем уже будет пару десятков постов, десяток читателей и новый опыт, который уверен тебе еще пригодится. 

Если у тебя есть другие вопросы на тему "как завести блог" - прошу поделись ими в комментах. Разберемся. 

среда, 1 апреля 2015 г.

Ликбез по многопоточности в Java

Беда с пониманием многопоточности? 
На собеседованиях спрашивают, а на проекте потом не дают мяса, чтобы нормально научиться? 
Может ты уже Middle или даже Senior, а тема все так же на Junior уровне, что аж стыдно за это?
Или ты Junior только что с собеседования, которое провалил в том числе из за вопросов по многопоточности? 

У меня то же это долго было белым пятном в моем резюме. Но как-то раз в мою жизнь постучалась возможность и билетом в нее был подготовленный доклад на тему многопоточности. Тренинг надо было провести, меня как тренера собирались собеседовать по теме той самой многопоточности. Нетворкинг рулит - нашелся сразу хороший ментор, который давал вводные, отпуска меня на пару дней рисерчить и после на митинге с ним мы обсуждали то, что я наковырял. Так 4-5 итераций и база была освоена. Понимание появилось. 


Тренинг в итоге отменился, но тему я решил закрепить. И ничего нет лучше закрепления новой темы, чем подготовить на ее тему доклад. Еще пару дней подготовки после чего доклад состоялся. И я его записал! А записью могу с тобой поделиться. И чтобы видяшка у тебя не залежалась на полке, я выставлю ей цену - ту сумму, которую заплатили те ребята, которые пришли на семинар.

Что ты получишь?
  • смонтированную видеозапись семинара (2,5 часа)
  • презентацию в формате mind map - она намного приятнее, чем простая плоская преза поскольку mind map специально лучшего усвоения информации людьми.
  • исходные коды всех примеров
  • исходники примеров и презентацию буду постоянно пополнять, потому ты единожды приобрев ее будешь иметь обновленную версию.
  • ссылки на полезные статьи которые находил пока рисерчил, например по вопросам на собеседовании
  • ссылки на книги, которые ты можешь купить и прочитать
  • а на все то, что по этой теме я придумаю после (вебинары. семинары) у тебя будет скидка 30%
Все это поможет тебе больше разобраться в теме.

Список покрытых топиков.
  • "паралельные" вычисления - разница Parallel vs Concurrency vs Distributed
  • какие проблемы решает Concurrency - проблему целостности данных
  • что такое шедулер операционной системы и его роль в многопоточности
  • процессы и потоки
  • реализация многопоточности в Java
  • запускаем Thread - способы запуска: через Runnable, через Thread   с помощью java.util.concurrent.Executors
  • состояние потока: new, runnable, running, waiting, blocked, sleeping, dead.
  • правильная и неправильная остановка stop() и interrupt()
  • сон в потоке :) метод sleep()
  • "спасибо, я - все" yield()
  • приоритеты потоков и на что они влияют
  • доступ к потоку из потока
  • присоединение к потоку join()
  • группа потоков, ThreadGroup
  • interrupt / interrupted / isInterrupted - основные грабли
  • потоки демоны
  • критическая секиця, synchronized, монитор
  • data race
  • методы Оbject - wait notify notyfyAll. Основные грабли
  • volatile
  • java memory model, happens before 
  • организация heap, stack
  • поверхностный обзор java.util.concurrent 
После оплаты ты получишь материалы на email.
(если этого не случилось, напиши apofig@gmail.com или оставь комментарий к этому посту - решим вопрос)

Все темы разбираются на поверхностном уровне. Цель семинара, дать обзор и направить в правильное русло. Дальнейшая проработка темы - требует твоей практики.

Успехов!