Я пользуюсь RSS сколько себя помню как разработчика. Когда-то очень давно для получения новой информации разработчику нужно было иметь список полезных блогов и сайтов, время от времени заходить туда и проверять нет ли чего нового почитать. Это отнимало кучу времени и быстро надоедало. С приходом RSS все изменилось – я добавлял все новые интересные фиды и они тут же попадали в единую ленту. Ну а с помощью Google Reader (который к моему большому сожалению умрет через 3 дня) можно было просматривать эту ленту на любом устройстве, отмечать понравившиеся статьи, сохранять их, делиться комментариями и т.д. В общем совсем другая жизнь.
И вот сегодня в twitter состоялся вот такой диалог:
Я слышу подобное мнение уже не в первый раз и хотел бы высказаться по этому поводу. Сначала о том, что я получаю от RSS. У меня несколько сотен подписок, которые за день дают около 100-200 записей. После быстрого разгребания остается 5-10 достойных к прочтению. Из них 2-3 действительно интересных. И так каждый день.
Теперь давайте рассмотрим альтернативные каналы. Я ими тоже пользуюсь, но трудозатраты для получения такого же выхлопа несравнимы.
Начнем с Twitter. Очень полезная штука, которую я люблю и постоянно пользуюсь. Но можно ли его использовать как постоянный источник для получения полезной информации? Я считаю, что нет. На данный момент я подписан на около 50 человек, многие из которых пишут редко. Просмотреть всю ленту занимает достаточно много времени, а уж открыть все ссылки я вообще молчу. Не представляю как это можно делать при количестве подписок в районе 300+. Twitter был придуман не для этого и представляет собой очень мусорный изначально канал. “Я в туалете”, “уже вышел и мою руки”, “а вот моя фотка около туалета”… Огромное количество шума мешает выделить из Twitter полезную информацию в таком объеме как из RSS. Но я бы сказал поверхностную информацию получить можно.
Следующим идет LinkedIn. Это вообще отдельная история. Я просматриваю ленту иногда, потому что некоторые товарищи стали писать исключительно туда. Просматриваю и каждый раз матерюсь. На одну полезную ссылку десяток объявлений о поиске кандидатов на вакансию, куча мусора о смене работы у знакомых. Ну и самое главное – ты можешь подписываться на тех, с кем ты знаком в сети. А их тех, с кем я знаком, минимальное количество людей что-то пишет толковое.
Дальше Google+ и Facebook (я надеюсь никто не предложит VK). Тоже иногда просматриваю и получаю меньше всего полезной информации. Количество расшаренных фотографий, статусов, приколов, “интересных” видео, “желтых” новостей и прочего просто зашкаливает. Не представляю как серьезно настроить ленту для фильтрации полезной информации. Да и по задумке не для этого придумана социальная сеть, а для того, чтобы делиться своей жизнью, новостями, событиями. А сюда уж никак не вписываются статьи, тем более написанные кем-то другим для своего блога.
Вдобавок хочу сказать, что многие RSS каналы, на которые я подписан не представлены на социальных сетях. Это не один человек, который пишет с свой бложек, а большие ресурсы с множеством авторов. Может я просто чего-то не понимаю и представляю старое поколение? Почему тогда столько толковых людей (на мой взгляд толковых) ищет замену Google Reader? 😉
P.S. Благодаря Саше Белецкому у меня стоит в iPad великолепное приложение Flipboard, с помощью которого я и просматриваю все перечисленные каналы.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
С началом лета встречи “Клуба анонимных разработчиков” стали реже. Но мы не забыли о клубе и постоянно работаем над новыми интересными темами для встреч. В следующий четверг 4 июля состоится очередная встреча.
Темой встречи выбрано back-end performance testing для разработчиков. Мы рассмотрим когда и для чего нужно performance тестирование. Какие виды ошибок и как можно обнаружить, используя разные виды нагрузок. Сформулируем требования к платформе для проведения тестов. За “чашкой кофе” напишем базовый тест. Как наиболее распространенные, в докладе будут рассмотрены REST и SOAP API back-end решения. Из инструментов для тестирования подробно разговор пойдет о Apache jMeter (JVM-based, BeanShell, Java) и loadUI (JVM-based, Groovy).
Докладчиком выступит Андрей Заричный, тестировщик-автоматизатор в компании e-conomic (hosted by Ciklum). В данным момент он работает над автоматизацией функционального и нагрузочного тестирования debitoor.com. Ранее работал над автоматизацией и тестированием производительности у одного из крупнейших провайдеров рекламы.
Встреча пройдет в четверг 4 июля. Место встречи еще окончательно не выбрано и будет оглашено позже. Официальное начало встречи по-прежнему в 19:00, завершение в 23:00. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 60 участниками.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Я уже упоминал в предыдущих статьях, что посетил конференцию GeekOUT 2013, которая проходила 12-14 июня в Таллине. Таллин оказался очень приятным городом: старый город особенно хорош и красив, достаточно много парков, недалеко море, не такое насыщенное автомобильное движение как в Киеве. К Таллину мы еще вернемся в конце статьи, а пока о конференции.
Начнем с того, что мне очень понравилась площадка для проведения самой конференции. Большой просторный главный зал, который в основное время служит театральной сценой, очень удобен для проведения докладов. Плюс много разного размера залов для мастер-классов, обсуждений и дискуссий. Я был приятно удивлен, потому что площадка построена еще в советское время и являлась Домом Культуры. Но теперь видно попала в хорошие руки.
Отдельного внимания заслуживает холл. Он был отлично оборудован плазмами в центре зала, благодаря чему с балконов второго этажа можно было легко наблюдать за демонстрациями продуктов. Это еще одна интересная идея организаторов – в перерывах на кофе давать возможность разным компаниям показывать свои продукты, которые имеют отношение к разработке на Java. Очень удобно – пьешь кофе и смотришь демо. Сами же стенды компаний располагались в холле и каждый мог подойти пообщаться и посмотреть демо от сотрудников компании, задать интересующие вопросы и набрать сувениров. 🙂
Еще приятно удивила работа интернета. Он был стабилен и работал без нареканий. Такую же картину можно наблюдать по всему Таллину. В каждом заведении есть интернет и многие точки не запаролены, поэтому на улице часто можно без проблем найти точку и подключиться. В общем, в Таллине с интернетом все отлично!
Обед и кофе-паузы тоже были неплохие, кейтеринг работал четко и слаженно. Мне понравилась идея с графинами холодной воды с кусочками лимона, лайма и апельсина. Достаточно просто и удобно.
Ну а афетпати в первый день конференции было вообще отлично организовано. Пиво, вино, еда и самое главное много места для общения. Недалеко от места проведения конференции было арендовано заведение в большом ангаре. Поэтому влезли все и это здорово! Мы отлично провели время и потом двинули в центр за продолжением.
Теперь кратенько о докладах. Многие из них были недостаточно техническими или с узкой практической направленностью, но тем не менее было интересно.
Открывал конференцию Geert Bevin, который в своем докладе продемонстрировал достижение современных технологий – музыкальный инструмент, который судя по демонстрациям может все. Причем снимает данные о движении рук, самого музыканта и окружающей обстановке, а потом из всей этой информации делает музыку. Это реально круто!
За ним выступил Attila Szegedi с философским докладом о сложности систем и вычислений. Главный вывод – не создавайте сложности там, где это не нужно и пишите простые системы для решения задач бизнеса.
Доклад Kohsuke Kawaguchi я пропустил, потому что не вижу смысла в Jenkins когда есть TeamCity. 😉 Следующий доклад был от Juergen Hoeller о будущем Spring 4 и Java 8. Я ожидал чего-то нового и интересного, но в очередной раз прошлись по больным местам Java, узнали что Spring 4 выпустит поддержку Java 8 раньше самой Java 8, а еще что Java 8 уже работает неплохо в заявленной комплектации. Самым интересным фактом стало то, что разработчики Spring спрыгивают с Eclipse и переходят на IDEA, потому что в ней уже есть ранняя поддержка Java 8.
Последний доклад в первый день был от Tobias Lindaaker об инструментах в JDK, которые могут помочь делать разные хаки с вашим кодом. К примеру, при падении теста поставить туда break point или добавить поведение к методу. И даже затронули класс Instrumentation с его методом getObjectSize для любителей позамерять. Такие вещи полезно знать, но они редко применимы, если только вы не разрабатываете инструмент для разработчиков или библиотеку.
Во второй день работало уже два потока, поэтому приходилось выбирать. Первым докладом я выбрал Attila Szegedi с его отчетом о состоянии дел в работе других языков на JVM. Сам Atilla трудится над Nashorn чтобы дать разработчикам удобный инструмент для запуска JavaScript. В докладе было много живого кодирования и демонстраций. Получился очень полезный обзор для расширения кругозора.
Дальше я остался на главной сцене на совсем не технический доклад от Sven Peters из Atlassian. Доклад назывался “How To Do Kick-Ass Software Development” и не имел никакого отношения к Java. Это был рассказ о том, как в компании Atlassian строят процессы разработки, какие практики применяют и как использую Agile подходы и принципы. Agile не умер, вы просто не умеете с ним жить! 🙂 Доклад был мега-ярким и позитивным.
После обеда заглянул на доклад Вовы Иванова о JIT. В очередной раз понял, что JIT много чего умеет и с каждым годом берет на себя все больше работы по ускорению кода на JVM. А это немаловажно для скептиков относительно скорости работы Java.
Дальше был доклад Andres Almiray об AST трансформациях и как классно они работают в Groovy. Действительно, можно одной аннотацией генерировать кучу кода или реализовывать шаблоны дизайна: @Singleton, @Immutable, @Lazy и другие. Это сильно упрощает код приложения, уменьшает число потенциальных ошибок и открывает возможности к повторному использованию целых решений. Да и сам докладчик был очень бодрый и активный, что добавило докладу живости.
Последнее выступление было от Talip Ozturk на тему его детища Hazelcast. Если вы еще не знаете, что это такое, то обязательно посмотрите. Очень простое распределенное хранилище данных с натуральным доступом через Java API многим приложениям очень бы пригодилось. Я не имел возможности послушать этот доклад на JEEConf 2013, поэтому тут наверстал упущенное.
Отдельное спасибо хочу сказать ребятам из ZeroTurnaround (особенно Антону Архипову и Олегу Шелаеву) за отличную конференцию, пригласительный для меня, много интересного общения и полезные советы по проведению времени в Таллине. Мы посетили практически все интересные места в старом городе, я забрался на самую высокую башню, погуляли по большому и очень красивому парку с фонтанами, увидели какое оно северное море, я организовал себе несколько пробежек, посетили морской музей и отлично провели время. Буду рад приехать в следующем году!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Пока злость не улеглась надо написать эту статью. Сразу предупреждаю, что статья содержит грубости и представляет исключительно мой опыт и видение ситуации. Кому все таки любопытно, добро пожаловать.
У меня очень негативное отношение к слову “стартап”. Причин несколько. Одна из них заключается в том, что большая часть из того, что называют в современном мире “стартапами” – просто унылое никому не нужное говно, которое появилось на свет благодаря буму социализации и невнятным попыткам некоторых разработчиков “сказочно разбогатеть”. Это касается как зарубежных, так и отечественных стартапов. Достойных проектов среди них 0.01%, а технически грамотно реализованных и того меньше.
Вторая причина скорее относится к нашим отечественным “стартапам”. В современном мире большая часть новых проектов направлены на предоставление сервиса. Сервиса, который сделает жизнь пользователей проще, приятнее, безопаснее и всячески клевее. В украинской версии “сервис” сводится только к зарабатыванию денег на пользователях и уходе от какой-либо ответственности за некорректную работу.
Итак, чем же мне насолили? Давайте сначала, чтобы не быть голословным, я приведу ссылку об отношении сервиса к “звездным” отечественным стартапам. Речь пойдет о tickets.ua, который как вы видите занимает почетное 15-ое место, а также о его “собрате” – senturia.ua. Оба сервиса предоставляют возможности бронирования и покупки билетов.
Начнем с senturia.ua. Я вообще стараюсь как можно меньше пользоваться отечественными приложениями по заказу билетов и предпочитаю сайт авиакомпании (если нет большой разницы в цене) или проверенные сервисы как Kayak, Expedia, Orbitz и т.д. Но тут возникла сложность – лететь надо было в Эстонию с Estonian Air (только у них есть прямой рейс в Таллин) и все мои попытки заказать билеты на сайте компании заканчивались неудачно. Но об Estonian Air пожалуй отдельно. 🙂
Итак, я нашел рейс, ввел все данные о пассажирах, информацию для оплаты кредитной картой, проверил правильность данных о рейсе и смело нажал на кнопку оплаты. Каково же было мое удивление, когда ни через минуту, ни через 10 минут я не получил никакого письма от сервиса о судьбе моего заказа. Вообще ничего! При этом деньги с карты снялись мгновенно. Я подождал еще и понял, что надо обращаться в службу поддержки.
Тут начинается классический знакомый многим не по наслышке отечественный сервис. Раза 3-4 мне обещали разобраться в проблеме в течение 30 минут, максимум часа. На вопрос что случилось и почему с моей карты сняли деньги без реального бронирования билетов никто ответить не мог. Прошли почти сутки. В результате моих многократных звонков в службу поддержки и угрозе сообщить в банк о пропаже денег с моего счета (что можно довести до внесения получателя в черный список) мне вернули деньги, прислав сухое письмо об отмене моего бронирования, подписанное Юлией 559. Шикарно!
После этого я совершил вторую ошибку и воспользовался tickets.ua. Мне понравился простой интерфейс, где после выбора маршрута с датами, заполнения информации о пассажирах и карте на той же странице, оплата была совершена. Выбор полей был минимальным и никакая дополнительная информация не отвлекала. Деньги сразу не сняли, прислали уведомление о бронировании. После этого часть денег ушла напрямую компании Estonian Air, а часть tickets.ua. Сразу после этого мне прислали билеты на рейс. После опыта с senturia.ua я остался доволен. Но не тут то было…
Спокойно улетев из Киева в Таллин, на обратном пути в аэропорту у стойки регистрации выяснилась неприятная особенность – обратный рейс у меня был без багажа. Сотрудники авиакомпании объяснили, что билет заказан на разные типы сервиса в оба конца и что эконом у них бывает разный. Вспоминаете ту минималистичную форму заказа билетов? За ее внешним удобством для покупателя скрывается система, которая принимает решения на свое усмотрение. Узнать о том, что обратный рейс предоставляется без багажа, можно было по записи 0PC в одном из полей детальной маршрутной квитанции на обратный рейс. Никаких предупреждений, просто одно из полей мелким шрифтом в маршрутной квитанции. Можно было такое предположить? Я за многие годы полетов с такой проблемой сталкиваюсь впервые!
В результате, заказ на tickets.ua обошелся мне в дополнительные 40 евро, потраченное время и кучу головняка. Ну, думаю, по возвращение обращусь к ним и выслушаю извинения с компенсацией потраченных средств. Вместо этого получилось совсем наоборот. Я вернулся в режим отечественного сервиса. Мне начали доказывать, что во всем виноват я, который сам выбрал такой тип билета. Потом, в ответ на мой аргумент о невозможности его выбрать на сайте, виноватой вдруг стала авиакомпания, которая так забронировала билет. А потом мне и вовсе ответили, что их сервис заключается просто в передаче брони авиакомпании, а все остальное их просто не касается. Ах да, и мне же выслали маршрутную квитанцию с 0PC на обратный рейс.
Очень смешно рассказывать эту чушь разработчикам. Мы то прекрасно понимаем, что у авиакомпаний есть сервис, торчащий наружу, который делает то, что его попросили. Все ошибки, состыковки, обработка и подготовка данных, ложится на вызывающую сервис сторону. В данном случае это tickets.ua. Но оказывается она не несет за это ответственности.
Мне кажется, все дело в том, что у отечественных “стартаперов” отсутствует понимание сервиса и его целей, не говоря уже о лояльности к своим клиентам. Ошибки нужно признавать и принимать меры, чтобы клиент остался доволен в любом случае. Если ты берешься за определенную нишу, то надо в ней предоставлять именно сервис, делающий жизнь проще для клиентов. И не только тогда, когда все пошло по плану, но и когда появились проблемы.
В конце душеизлияния хотелось бы пару слов сказать о компании Estonian Air. Я достаточно часто летаю и привык оценивать уровень авиакомпании по цене на билеты. Дешевые билеты – вероятнее всего лоукостер и не стоит ничего ждать от него, дорогие – ты можешь ожидать неплохого сервиса. Estonian Air поломала стереотипы. Стоимость самого дешевого билета Киев-Таллин-Киев составляет около $300 при времени полета 1 час 30 минут. Его нельзя ни вернуть ни поменять. Что же вы получаете за эти деньги? А ровным счетом ничего:
А теперь самое интересное. В кармашке кресла как обычно можно найти журнал авиакомпании. И обычно на первой странице там руководство компании рассказывает о том, как их авиакомпания развивается, что хорошего ждет пассажиров, какие новости позитивные есть. И тут главные новости были о сокращении расходов. О том, что компания полгода провела в разработке стратегии по снижению затрат во всех областях, много людей уволили, урезали все что можно. Какое мне до этого дело? Стоимость услуг осталась такой же! Только пострадало качество предоставляемого сервиса. Так что в этом позитивного для пассажиров? Должны порадоваться, что теперь компания больше зарабатывает? И это очень напомнило мне наш отечественный сервис…
В общем, будьте аккуратны в своем выборе сервиса и не повторяйте моих ошибок.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Новые проекты постоянно стартуют, новые продукты начинают разрабатывать, а значит постоянно нужны новые хорошие команды, которые смогут привести проект к успеху. И тут появляется очень интересный вопрос: “кого нанимать в команду первым?”. Казалось бы, что тут сложного в этом вопросе? Оказывается, что ситуация на проекте может очень сильно измениться от одного или иного решения.
Давайте предположим, что первым вы решили взять в команду очень крутого специалиста, так сказать “звезду”. У вас как раз был такой на примете, вы его заинтересовали и пригласили в проект. Естественно, он будет принимать участие в отборе остальных членов команды. Но кого он будет пытаться отобрать? Вероятнее всего, таких же “звезд” как и он или немножко слабее. Для проекта это может превратиться в бесконечную волокиту в попытках расширить команду. Причины такого поведения просты – сильным разработчикам интереснее работать с другими сильными разработчиками. Зато, если вам повезет, вы получите небольшую, но очень сильную и замотивированную команду. Ведь каждый будет понимать, что это отличный шанс поработать действительно со “звездами”. Если же не повезет, то вы не сможете набрать быстро людей, проект загнется или же вы не выдержите и переключитесь на второй вариант.
Во втором варианте вы берете первым в команду хорошего середняка. И тут вступает в силу второй интересный принцип – середняк не будет нанимать людей сильнее себя. Это будут либо люди слабее его, на фоне которых он будет чувствовать себя “звездой”, либо такие же как он. В результате, вы можете достаточно быстро укомплектовать среднюю команду, но вам будет очень тяжело затащить туда сильного разработчика. Демотиватором для него будет уровень других членов команды. Да и для команды одного уровня приход такого сильного разработчика будет демотиватором. Но не факт, что средняя команда сможет сделать именно ваш продукт или проект на высоком уровне качества. А дальше может сложиться так, что середняки уйдут и уровень команды по тому же принципу упадет еще больше. И наступит болото…
Вот такой сложный выбор стоит перед тем, кто собирается набирать команду. Поэтому будьте внимательны и найдите для себя верную комбинацию.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Давненько я не писал провокационных статей. 🙂 Сегодня хочу поднять очень интересную тему программистов/разработчиков в возрасте. Обычно к данной категории относят представителей нашей индустрии, которым 40+ лет и кто по прежнему непосредственно занимается разработкой. IT сообщество делится на 2 лагеря: считающие возрастных разработчиков очень грамотными, полезными в компании и те, кто наоборот считает их бесполезной массой, от которой давно пора избавиться. Тема спорная, но я постараюсь осветить свой взгляд на нее.
Я являюсь сторонником второго лагеря, но только по отношению к отечественным разработчикам. И мне кажется, что причина в них самих. За рубежом все совсем не так. Итак, начнем. Во-первых, для большей части долго проработавших на отечественном рынке разработчиков в определенном возрасте работа перестает приносить драйв и становится просто способом зарабатывать деньги. На первых позициях давно семья и хобби. Это значит, нет времени на самообразование, да и смысла в нем они не видят особого. Пилят старый проект на аутсорсе и деньги получают.
Вторая причина очень тесно связана с первой. Наш рынок очень специфичный, на нем возрастные разработчики с высокими требованиями по зарплате и малой отдачей попросту невыгодны. Поэтому они ищут способ оставаться при деле. Очевидный выход – разбираться в древних технологиях, которые молодым поколениям практически неизвестны. Тогда ты всегда будешь оставаться востребованным специалистом, ведь старых больших проектов пруд пруди и многие из них отдают на аутсорсинг (не так много людей хотят за границей такой дрянью заниматься). При таком подходе можно найти себе “тепленькое место” и не переживать за ближайшее будущее.
Следующая причина – это публичная активность. Если хочешь, чтобы о тебе было хорошее мнение, надо его заслужить. Если ты много знаешь, то поделись знаниями с коллегами, научи молодое поколение уму-разуму. И где все “опытнейшие разработчики”? Почему их нет на встречах сообществ и конференциях? А там где есть, большая часть слушателей остаются недовольными? Может быть не такие уж они и опытнейшие? Все с удовольствием слушают Мартина Фаулера, дядю Боба, J. B. Rainsberger, David Evans и других представителей зарубежной IT индустрии. А где наши гуру? Окучивают EJB 2.0 на WebSphere или переливают данные из внешних вебсервисов в старенькую версию Oracle, продолжая работать на Java 1.4?
Ну и последняя причина – это сопротивление изменениям. На многих проектах я наблюдал одну и ту же картину как разработчики в возрасте становились большой преградой на пути внедрения новых подходов и технологий. Оно и понятно – эти изменения выбивают их из привычного окружения, требуют учить что-то новое, снова становиться начинающим из “эксперта”. Мы все сопротивляемся изменениям, которые выбивают нас из зоны комфорта. “Эти ваши Agile-шмаджайл, чего общаться? Код надо писать вместо этого!”. “Какой NoSQL? А ты потом будешь отвечать за потерянные транзакции?”. “Кто будет поддерживать эти open source поделки? Завтра их может уже не быть…”.
Я считаю, что для хорошего мнения о себе надо многое сделать. Возраст и опыт не создаст на ровном месте хорошего мнения. Его надо заслужить! Хотелось бы услышать ваше мнение на данную тему в комментариях. 🙂
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Совсем недавно отгремела конференция JEEConf 2013, перед ней в Одессе прошла локальная конференция для Java разработчиков Java Breeze, через неделю в Эстонии пройдет интереснейшая конференция GeekOut 2013. Но это не все – в конце месяца, 29 июня, Java разработчики будут иметь возможность еще раз встретиться на конференции JDay во Львове.
Программа конференции скоро будет опубликована, но уже собралось немало интересных докладов. Большая часть докладчиков русскоязычные, но это возможно и к лучшему – надо развивать свое сообщество и искать тех, кто может поделиться локальным опытом. Регистрация на конференцию уже открыта и билет можно купить очень дешево – всего 350 гривен.
Организаторы выбрали спорную дату, сразу после Дня Конституции, который в Украине является официальным праздником. С другой стороны, участники конференции смогут на 3 дня затусить во Львове. Я именно так и собираюсь сделать. Выступать в этот раз я буду с докладом об особенностях и проблемах обмена сообщениями в масштабируемых системах. Кто не был на JEEConf, будет иметь отличную возможность прокачаться в этих вопросах. Так что приезжайте! 🙂
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
