- закінчив курс learnpythonthehardway.org і прочитав learnxinyminutes.com по тому ж python. Відчув себе джуном-початківцем. Синтаксис мови тепер не викликає відторгнення, є бажання щось написати.
Lifehack про друкування коду прикладів - найкраща порада для освоєння нової мови програмування. - Сходив на morning.lohika.com по High Load, який провів гість з Києва Дмитро Думанський. Цікаво і добра вправа для голови. На планшет або телефон часу не було варто витрачати.
Відчував всю доповідь і сесію питань і відповідей - скільки ж ще мені вчити і отримувати досвід.
Але потім сходив на ленту автора на Хабрі, де були співпадіння з презентацією (а я читав лише статтю автора на доу, глибше не пішов, менше цікаво на доповіді не було), почитав коментарі.
Звичайно, хабровські троллі, які не ставлять у приклад власні проекти, а лише відмовляють авторові у цінності викладення матеріалів, порадували.
Але легше стало :)
Показаны сообщения с ярлыком работа. Показать все сообщения
Показаны сообщения с ярлыком работа. Показать все сообщения
суббота, 4 октября 2014 г.
Python і High Load Lohika morning
пятница, 3 октября 2014 г.
Краще ніж вчора
В рамках задуманого місячника "Сьогодні краще ніж вчора" почав із прояснення для себе що ж таке SOLID - принцип, про який мене досить часто питають на співбесідах.
Дуже вчасно під руку потрапили сторінки київського программіста-дотнетчика. Я підписаний на його блог, колись намагався погортати його, але застряг. Пише розумні речі, які в голову одразу не заходять. Статті він писав декілька місяців, але я терпляче чекав коли він допише всю серію по абревіатурі - щоб у голові все одразу вклалося.
І ось нещодавно він, здається, дописав.
Особливим успіхом похвалитися не можу, але сподіваюся, що наступного разу це питання мені не буде здаватися таким формальним, і я зможу про SOLID поговорити, а не просто відбарабанити завчені визначення. Я на всі 100% автора не зрозумів. Можливо, пізніше перечитаю і відчую просвітлення. Але зрушення були.
Якщо ви не я, то раджу читати прямо автора - в нього більше, розгорнуто, краще. Тут пишу більше для себе, конспектую виконання намагань стати сьогодні краще, ніж вчора.
Даний принцип стосується проектування і архітектури.
Отже, що як я тепер буду розшифровувати дану абревіатуру:
Дуже вчасно під руку потрапили сторінки київського программіста-дотнетчика. Я підписаний на його блог, колись намагався погортати його, але застряг. Пише розумні речі, які в голову одразу не заходять. Статті він писав декілька місяців, але я терпляче чекав коли він допише всю серію по абревіатурі - щоб у голові все одразу вклалося.
І ось нещодавно він, здається, дописав.
Особливим успіхом похвалитися не можу, але сподіваюся, що наступного разу це питання мені не буде здаватися таким формальним, і я зможу про SOLID поговорити, а не просто відбарабанити завчені визначення. Я на всі 100% автора не зрозумів. Можливо, пізніше перечитаю і відчую просвітлення. Але зрушення були.
Якщо ви не я, то раджу читати прямо автора - в нього більше, розгорнуто, краще. Тут пишу більше для себе, конспектую виконання намагань стати сьогодні краще, ніж вчора.
- S – Single Responsibility Principle
- O – Open-Closed Principle (Часть 2. ФП vs ООП)
- L – Liskov Substitution Principle (LSP. Часть 2. О наследовании)
- I – Interface Segregation Principle
- D – Dependency Inversion Principle (Критический взгляд на DIP)
- О принципах проектирования
Даний принцип стосується проектування і архітектури.
Отже, що як я тепер буду розшифровувати дану абревіатуру:
- S - Single Responsibility Priciple
Клас повинен мати лише одну причину для зміни.
Тобто потрібно так керувати складністю і розділяти відповідальність між класами, щоб наступні зміни в систему були якомога легшими, без тривалих досліджень і переробок. (Саме тому не варто покладати відповідальність на один і той же клас для роботи з базою даних і інтерфейсом користувача) - O - Open / Close Principle
Програмні конструкти повинні бути відкритими для змін і закритими для модифікації.
Мова йдеться про стабільність (закритість для змін) інтерфейсу взаємодії програмних конструктів і вільність зміни їх реалізації.
Теж боротьба із складністю внесень в систему архітектурних змін. - L - Liskov Substitution Principle
Повинна бути можливість заміни базового класу на його похідний.
Автор пише про збереження дизайном умов контракту при змінах у системі. - I - Interface Segragation Principle
Зменшення зв'язності за рахунок розділення інтерфейсів для конструкту, які можуть використувувати різні клієнти. - D - Dependency Inversion Principle
Модулі верхнього рівня не повинні залежати від модулів нижнього рівня, і обоє повинні залежати від абстракцій. Абстракції не повинні залежати від деталей, деталі повинні залежати від абстракцій.
Заміна композиції агрегацією. Залежності вносяться зовні (через параметри методів чи конструкторів), а не закладені намертво в клас.
среда, 25 июня 2014 г.
Enterprise
Нещодавно усвідомив, що переклад і осмислення слова "Enterprise" допомагають позбавитися "ментального лоску", "тремтіння" перед таким поняттям, як "Java Enterprise Edition".
Моя проблема була в тому, що до цього часу я асоціював це слово більше із корпорацією, ніж із "банальним" підприємством.
Корпорація - це монстр, якого не соромно боятися.
А підприємство - воно ж може бути і скромним державним.
Чого його боятися?
Моя проблема була в тому, що до цього часу я асоціював це слово більше із корпорацією, ніж із "банальним" підприємством.
Корпорація - це монстр, якого не соромно боятися.
А підприємство - воно ж може бути і скромним державним.
Чого його боятися?
вторник, 13 августа 2013 г.
Праздники
Год назад вышел на работу в львовский офис Логики.
Из безусловных плюсов, кроме зарплаты, двухнедельная поездка в Дублин, двухнедельный отпуск когда у меня родился сын, и, конечно, люди у которых есть чему поучиться.
А еще сегодня оказывается международный день левши
Задумался...
Из безусловных плюсов, кроме зарплаты, двухнедельная поездка в Дублин, двухнедельный отпуск когда у меня родился сын, и, конечно, люди у которых есть чему поучиться.
А еще сегодня оказывается международный день левши
Задумался...
четверг, 27 июня 2013 г.
Ошибки
Самое большое количество ошибок у меня появляется из-за невнимательности.
Я подкован в теории, и когда мне начинают объяснять, или мне приходится искать ошибку самому - понимание приходит быстро, и часто вознивает ощущение повторения очевидных вещей.
Когда я сфокусирован - ошибки редки. Отсутствие концентрации или не достаточное ее количество портят дело.
Так было еще со времен школы.
Я подкован в теории, и когда мне начинают объяснять, или мне приходится искать ошибку самому - понимание приходит быстро, и часто вознивает ощущение повторения очевидных вещей.
Когда я сфокусирован - ошибки редки. Отсутствие концентрации или не достаточное ее количество портят дело.
Так было еще со времен школы.
вторник, 18 июня 2013 г.
Последняя капля для eclipse
Наверное, у каждого подобное должно бы происходить по своему: я о смене рабочего инструмента.
Я работаю программистом. Мой рабочий инструмент - IDE. Интегрированная Среда Разработки, как бы неприлично это не выглядело в русской аббревиатуре. Для меня очень важны удобство, простота и функциональность.
Уже несколько лет подряд рядом с eclipse никто не стоял. В сторону idea смотрел, но каждый раз находил ее слишком сложной для усвоения. И платность отталкивала...
Первым звонком для меня стала возможность работы из коробки с Maven. Попробовал, и оказалось, что структурированный xml Maven'а достаточен для того, чтобы не редактировать самому файл проекта привычным добавлением плагина, чтобы сгенерировать служебные файлы для eclipse. Ведь ни один из двух плагинов для eclipse почему-то адекватно не работает. А в idea ничего дополнительно делать не надо. Более того - редактор в idea почему-то удобнее, и зависимости удобно просматриваются.
Следующим шагом был курс по MongoDB. Авторы видео-уроков иногда используют idea. Мне понравились буквенные вставки, которые можно было развернуть в код.
psv превращался в уже надоевший public static void main(String[] args) { ... }. Установил idea, повторял за видео.
А сегодня понадобилось вытащить из удаленного репозитория git код проекта. Не смотря на попытку следовать предоставленному списку того, что надо делать с eclipse, чтобы получить доступ к коду закрытому на доступ только по ключам, я провалился. Да, я и раньше испытывал неудобство в том, как git работает в eclipse. Но путанница, когда устанавливаемые из встроенного магазина плагины на смогли сами разобраться со своими зависимостями, утомила.
Поставил idea. Да, была своя путанница с ключами: настройки подгрузить ключи для репозиториев или среды разработки я не нашел. Но гугл помог понять, что idea сама найдет ключи, если их поместить в ожидаемое место (я был на RedHat 6.3, и каталог должен был быть $HOME/.ssh/. Для моего пользователя root $HOME = /root/ Я не сразу догадался проверить).
После этого надо было только вбить адрес репозитория, логин и пароль. Остальное среда разаработки, как и ожидалось, сделала за меня.
Да, я мог бы и вручную произвести все нужные операции. Но это уже не интерестно, и неудобно, когда должен отвлекаться на чтение логов в консоли.
Собираюсь переходить на idea.
Я работаю программистом. Мой рабочий инструмент - IDE. Интегрированная Среда Разработки, как бы неприлично это не выглядело в русской аббревиатуре. Для меня очень важны удобство, простота и функциональность.
Уже несколько лет подряд рядом с eclipse никто не стоял. В сторону idea смотрел, но каждый раз находил ее слишком сложной для усвоения. И платность отталкивала...
Первым звонком для меня стала возможность работы из коробки с Maven. Попробовал, и оказалось, что структурированный xml Maven'а достаточен для того, чтобы не редактировать самому файл проекта привычным добавлением плагина, чтобы сгенерировать служебные файлы для eclipse. Ведь ни один из двух плагинов для eclipse почему-то адекватно не работает. А в idea ничего дополнительно делать не надо. Более того - редактор в idea почему-то удобнее, и зависимости удобно просматриваются.
Следующим шагом был курс по MongoDB. Авторы видео-уроков иногда используют idea. Мне понравились буквенные вставки, которые можно было развернуть в код.
psv превращался в уже надоевший public static void main(String[] args) { ... }. Установил idea, повторял за видео.
А сегодня понадобилось вытащить из удаленного репозитория git код проекта. Не смотря на попытку следовать предоставленному списку того, что надо делать с eclipse, чтобы получить доступ к коду закрытому на доступ только по ключам, я провалился. Да, я и раньше испытывал неудобство в том, как git работает в eclipse. Но путанница, когда устанавливаемые из встроенного магазина плагины на смогли сами разобраться со своими зависимостями, утомила.
Поставил idea. Да, была своя путанница с ключами: настройки подгрузить ключи для репозиториев или среды разработки я не нашел. Но гугл помог понять, что idea сама найдет ключи, если их поместить в ожидаемое место (я был на RedHat 6.3, и каталог должен был быть $HOME/.ssh/. Для моего пользователя root $HOME = /root/ Я не сразу догадался проверить).
После этого надо было только вбить адрес репозитория, логин и пароль. Остальное среда разаработки, как и ожидалось, сделала за меня.
Да, я мог бы и вручную произвести все нужные операции. Но это уже не интерестно, и неудобно, когда должен отвлекаться на чтение логов в консоли.
Собираюсь переходить на idea.
четверг, 25 апреля 2013 г.
Неудачнеги?
Недавно прочитал (и никак не могу найти где) о том, что в отличии от ауотсорсеров, которые зарабатывают для страны порядка миллиарда долларов (на 2011 год, вроде бы), заробитчане пересылают домой порядка трех (на самом деле больше - раз, два). И пока есть такие выехавшие - можно перебиться и без аутсорсинга.
И не то, что стало обидно, но сегодня подумал сравнить эффективность.
Согласно последним (за 2012 год правда) оценкам суммарное количество сотрудников пятерки самых крупных компаний-аутсорсеров порядка 10 тысяч, топ 25 - порядка 20 тысяч. Ну, пусть суммарное всех, вместе с неучтенными, будет 100, даже 200 тысяч (нереально, по-моему).
Согласно другим данным, на заработки выехало около полтора миллиона и больше. Я думаю - порядка трех миллионов.
Тоесть, заробитчан по количеству в раз 10-15 больше, а пересылают они домой только раза в три больше чем аутсорсеры легально наколбасили.
Конечно, в этом, наверное особой заслуги ит-аутсорсеров нет - коньюнктура растущего мирового рынка. Но пока что один парень сидящий дома в Украине обеспечивает денежный поток в страну в разы больше, чем уехавший на заработки.
И семьи из-за этого не разваливаются, в отличии от заробитчан.
И не то, что стало обидно, но сегодня подумал сравнить эффективность.
Согласно последним (за 2012 год правда) оценкам суммарное количество сотрудников пятерки самых крупных компаний-аутсорсеров порядка 10 тысяч, топ 25 - порядка 20 тысяч. Ну, пусть суммарное всех, вместе с неучтенными, будет 100, даже 200 тысяч (нереально, по-моему).
Согласно другим данным, на заработки выехало около полтора миллиона и больше. Я думаю - порядка трех миллионов.
Тоесть, заробитчан по количеству в раз 10-15 больше, а пересылают они домой только раза в три больше чем аутсорсеры легально наколбасили.
Конечно, в этом, наверное особой заслуги ит-аутсорсеров нет - коньюнктура растущего мирового рынка. Но пока что один парень сидящий дома в Украине обеспечивает денежный поток в страну в разы больше, чем уехавший на заработки.
И семьи из-за этого не разваливаются, в отличии от заробитчан.
вторник, 12 июля 2011 г.
Будда в каждом из нас
Вот и прошло три месяца с момента как я вышел на работу.
Пора вспомнить самое значительное и попытаться этим значительным поделиться - хотя бы с собой будущим, который перечитает когда-то эти строчки.
Работу я искал сначала в Киеве, а уже потом в родном Львове.
Чесно скажу, в Киеве меня "проверяли на прочность" жестче. С другой стороны, вокруг нас одни вероятности, и я не застрахован от случайности. Или, например, различий между "продуктовыми" и "аутсорсинговыми" компаниями.
В Киеве я был на собеседованиях определенно в компаниях, которые выпускают собственный продукт.
Во Львове же меня взяли в аутсорсинговую компанию.
Еще различия - в Киеве искал через сайты, во Львове помогли с прямыми контактами на рекрутеров. Так что в Киеве было медленнее, а во Львове получилось так что договариваться о собеседованиях пришлось еще до приезда в сам город.
Во Львове показалось, что нужда в программистах больше, почему-то. Не смотря на то, что темп жизни медленнее, чем в Киеве, сам процесс выхода на работу прошел очень быстро. Буквально за пару дней я уже был трудоустроен.
Что хочу посоветовать и себе, и всем: меньше эмоций на собеседованиях, и особенно после них - не опускать руки, постоянно ходить собеседоваться. Надо думать, а не переживать свои временные неудачи. Надо эмоционально отстраниться от процесса, смотреть на результат, запоминать вопросы, искать на них (дома) ответы. Надо отыскать в себе маленького зачаточного будду, отстраненного от собственных эмоций и внешнего мира, и (временно!) посадить его за руль управления организмом.
Я подозреваю, конечно, что мне повезло с благоприятной для соискателей поработать общей обстановкой на рынке работы программистов Java. Но, все же думаю, что результат при системном подходе, с постоянными, ежедневыми походами на интервью, был бы тот же. На работу меня бы, может быть, и значительно позже, но взяли бы.
Я решил вопрос своего трудоустройства на третьем собеседовании. Раньше было бы неинтерестно и неспортивно :)
Еще совет: стараться назначать только одно интервью в день. Обычно я сначала проводил около часа с рекрутером. Дальше часа два на техническом интервью, на котором не напрягаться не получалось - эмоционально, умственно или физически - хоть что-то одно, но утомляло. А после него просто даже ехать куда-то уже было внапряг. А на собеседовании надо быть бодрым и голодным, действительно хотеть получить место.
Еще: каждый день учиться, не сидеть без дела.
Поиски работы та же работа, но с неизвестным вознаграждением и потраченным временем.
А дальше, как говориться - чем больше работать, тем больше тебе везет ;)
Пора вспомнить самое значительное и попытаться этим значительным поделиться - хотя бы с собой будущим, который перечитает когда-то эти строчки.
Работу я искал сначала в Киеве, а уже потом в родном Львове.
Чесно скажу, в Киеве меня "проверяли на прочность" жестче. С другой стороны, вокруг нас одни вероятности, и я не застрахован от случайности. Или, например, различий между "продуктовыми" и "аутсорсинговыми" компаниями.
В Киеве я был на собеседованиях определенно в компаниях, которые выпускают собственный продукт.
Во Львове же меня взяли в аутсорсинговую компанию.
Еще различия - в Киеве искал через сайты, во Львове помогли с прямыми контактами на рекрутеров. Так что в Киеве было медленнее, а во Львове получилось так что договариваться о собеседованиях пришлось еще до приезда в сам город.
Во Львове показалось, что нужда в программистах больше, почему-то. Не смотря на то, что темп жизни медленнее, чем в Киеве, сам процесс выхода на работу прошел очень быстро. Буквально за пару дней я уже был трудоустроен.
Что хочу посоветовать и себе, и всем: меньше эмоций на собеседованиях, и особенно после них - не опускать руки, постоянно ходить собеседоваться. Надо думать, а не переживать свои временные неудачи. Надо эмоционально отстраниться от процесса, смотреть на результат, запоминать вопросы, искать на них (дома) ответы. Надо отыскать в себе маленького зачаточного будду, отстраненного от собственных эмоций и внешнего мира, и (временно!) посадить его за руль управления организмом.
Я подозреваю, конечно, что мне повезло с благоприятной для соискателей поработать общей обстановкой на рынке работы программистов Java. Но, все же думаю, что результат при системном подходе, с постоянными, ежедневыми походами на интервью, был бы тот же. На работу меня бы, может быть, и значительно позже, но взяли бы.
Я решил вопрос своего трудоустройства на третьем собеседовании. Раньше было бы неинтерестно и неспортивно :)
Еще совет: стараться назначать только одно интервью в день. Обычно я сначала проводил около часа с рекрутером. Дальше часа два на техническом интервью, на котором не напрягаться не получалось - эмоционально, умственно или физически - хоть что-то одно, но утомляло. А после него просто даже ехать куда-то уже было внапряг. А на собеседовании надо быть бодрым и голодным, действительно хотеть получить место.
Еще: каждый день учиться, не сидеть без дела.
Поиски работы та же работа, но с неизвестным вознаграждением и потраченным временем.
А дальше, как говориться - чем больше работать, тем больше тебе везет ;)
Подписаться на:
Сообщения (Atom)
