В дополнение к вчерашней статье "Документы перед выездом из РФ".
Вводные: вы уезжаете из России или Беларуси, но там остаются дела.
Вывод: задерживаться только из-за этого не надо, дела можно делегировать с помощью доверенностей выданных зарубежем.
Artem Zinnatullin @Artem_zin
абстрактный мужик
Пост для мотивации: как я инвестирую в акции
22 мин
Дисклеймер
- этот документ не является финансовым советом, прост личные мысли по поводу инвестиций, компаний
- почему я инвестирую в компании, а не крипту/недвиж/крышечки от пива (крипта, недвиж и крышечки у меня, конечно, есть): цель коммерческих компаний — зарабатывать деньги, цель валюты/крышечек — быть средством обмена, а недвиж/etc — заморозить $ где-то вокруг инфляции, ну или как-то так, я инженер, а не экономист, сильно не бейте ¯*(ツ)*/¯
- мои принципы инвестирования оч простые:
RE: 23 минуты. Оправдание тугодумов
2 мин
to: %username%
cc: nmivan
bcc:
Я всегда думал, что я – тупой. Точнее, что я — тугодум.
Штош.
Мы с Володей Тагаковым (а он, кстати, в Яндексе работал) обсудили эту тему. Володя был согласен с посылом статьи, в то время как я — не был. Мы 23 дня копили мысли про это в фоновом режиме, а потом сели и обсудили под запись в виде подкаста. Ниже наша попытка выразить эти мысли в виде статьи. Дабы не переходить на личности и не использовать обидное слово тугодум, мы будем использовать "многодум".
Мы пришли к выводу, что посыл оригинальной статьи деструктивен по отношению к коллегам многодума: можно не участвовать в дискуссиях на митингах, а вместо этого
после совещания – через час, день или неделю – присылаю варианты решения.
Дорога ложка к обеду!
Ответ на пост «Презумпция ума»
1 мин
Данный пост является ответом на пост "Презумпция ума" от zolotyh, соответственно, для лучшего понимания, рекомендуется прочтение оригинала (он короткий и интересный).
Принцип "Презумпция ума", предложенный в оригинале, обозначен так:
Все люди умны и адекватны, если не доказано обратное.
С этим сложно согласится, так как, очевидно, люди бывают разные, их умственные возможности могут разниться очень и очень сильно, duh.
Однако, примеры и посыл у статьи хороший, автор, скорее всего, на верном пути (meta).
Введенный принцип, однако, достаточно неправильный.
StorIO — человеческий API для работы с SQLiteDatabase и ContentResolver
3 мин
Не секрет, что API SQLiteDatabase и ContentResolver — отстой, поэтому многие стараются от них абстрагироваться. Кто-то выбирает ORM, кто-то DAO, кто-то пишет своё.
За долгие годы Android разработки мы прошли через все эти этапы: ORM часто становится узким местом в критический для проекта момент, своё DAO требует тестирования и разработки, что отнимает много времени, которое можно было тратить на другие детали реализации приложения, готовые DAO в принципе решают вопрос, но различные библиотеки имеют свои плюсы и минусы (15стандартов.jpg), посмотрите, что предлагаем мы:
1. API для людей: удобные билдеры (помните 5-7 nullов в запросах?), читаемые и очевидные конструкции, Immutability и Thread-safety.
2. Упрощенный набор операций: вместо стандартного CRUD (Create-Read-Update-Delete или Insert-Select-Update-Delete) мы предлагаем три операции — Put, Get, Delete, при этом вы имеете полный контроль над их реализацией, можете, например, упороться и хранить один объект в нескольких таблицах и так далее.
3. Опциональный Type-Safe Object Mapping без Reflection, но если вы хотите работать с Cursor или ContentValues — пожалуйста.
4. Некая схожесть с Retrofit: вы можете выполнить любую операцию как блокирующий вызов либо как rx.Observable, мы можем добавить callback модель выполнения операций в будущем.
5. Reactive — Observable из Get операции будет получать уведомления об изменении таблиц в случае SQLite или Uri в случае ContentResolver, это позволяет полностью заменить лоадеры, API которых просто отвратителен.
За долгие годы Android разработки мы прошли через все эти этапы: ORM часто становится узким местом в критический для проекта момент, своё DAO требует тестирования и разработки, что отнимает много времени, которое можно было тратить на другие детали реализации приложения, готовые DAO в принципе решают вопрос, но различные библиотеки имеют свои плюсы и минусы (15стандартов.jpg), посмотрите, что предлагаем мы:
1. API для людей: удобные билдеры (помните 5-7 nullов в запросах?), читаемые и очевидные конструкции, Immutability и Thread-safety.
2. Упрощенный набор операций: вместо стандартного CRUD (Create-Read-Update-Delete или Insert-Select-Update-Delete) мы предлагаем три операции — Put, Get, Delete, при этом вы имеете полный контроль над их реализацией, можете, например, упороться и хранить один объект в нескольких таблицах и так далее.
3. Опциональный Type-Safe Object Mapping без Reflection, но если вы хотите работать с Cursor или ContentValues — пожалуйста.
4. Некая схожесть с Retrofit: вы можете выполнить любую операцию как блокирующий вызов либо как rx.Observable, мы можем добавить callback модель выполнения операций в будущем.
5. Reactive — Observable из Get операции будет получать уведомления об изменении таблиц в случае SQLite или Uri в случае ContentResolver, это позволяет полностью заменить лоадеры, API которых просто отвратителен.
Легковесная библиотека для Warning сообщений от javac через аннотацию
1 мин
Java разработчикам привет.
Делюсь легковесной (3kb) библиотекой, единственная и основная задача которой — кидать ворнинги от Java компилятора.
Использование очень простое: пишите аннотацию Warning(«Reason text here») и при компиляции будет выдан ворнинг (сборка при этом не останавливается).
Использован Annotation Processor API.
Гитхаб: https://github.com/pushtorefresh/javac-warning-annotation (опубликовано в mavenCentral)
Надеюсь, будет полезно.
P.S. В большинстве случаев лучше заводить задачу в тасктрекере вместо использования данной аннотации, но для некоторых вещей такой вариант вполне уместен.
Делюсь легковесной (3kb) библиотекой, единственная и основная задача которой — кидать ворнинги от Java компилятора.
Использование очень простое: пишите аннотацию Warning(«Reason text here») и при компиляции будет выдан ворнинг (сборка при этом не останавливается).
// some code...
@Warning("Refactor as soon as possible please")
public void someCodeWhichYouNeedAtTheMomentButYouWantToRefactorItLater() {
// bad stuff going on here...
}
Использован Annotation Processor API.
Гитхаб: https://github.com/pushtorefresh/javac-warning-annotation (опубликовано в mavenCentral)
Надеюсь, будет полезно.
P.S. В большинстве случаев лучше заводить задачу в тасктрекере вместо использования данной аннотации, но для некоторых вещей такой вариант вполне уместен.
Android last.fm скробблер WAIL Beta теперь Open Source
4 мин
Привет. Примерно полгода назад я запилил Android приложение для скробблинга проигрываемой в разных плеерах музыки в last.fm.
Уже несколько месяцев у меня нет времени развивать этот проект, поэтому я решил открыть его исходники (репозиторий на гитхабе).
Я пишу этот пост на Хабр с небольшой надеждой на то, что здесь есть люди, которым было бы интересно развивать WAIL дальше, добавлять новые фичи, фиксить баги и просто участвовать в оупен-сорс проекте Android приложения :)
Кратко о last.fm: это сервис для любителей послушать музыку, главная фича которого заключается в том, что вы можете передавать инфомацию о треках, которые вы слушаете, а last.fm на основе этого будет предлагать вам других исполнителей, друзей, концерты исполнителей, которых вы слушаете (кстати офигенно, первый раз сходил на концерт именно по рекомендации last.fm).
Скриншоты для поддержания интереса
Уже несколько месяцев у меня нет времени развивать этот проект, поэтому я решил открыть его исходники (репозиторий на гитхабе).
Я пишу этот пост на Хабр с небольшой надеждой на то, что здесь есть люди, которым было бы интересно развивать WAIL дальше, добавлять новые фичи, фиксить баги и просто участвовать в оупен-сорс проекте Android приложения :)
Кратко о last.fm: это сервис для любителей послушать музыку, главная фича которого заключается в том, что вы можете передавать инфомацию о треках, которые вы слушаете, а last.fm на основе этого будет предлагать вам других исполнителей, друзей, концерты исполнителей, которых вы слушаете (кстати офигенно, первый раз сходил на концерт именно по рекомендации last.fm).
Скриншоты для поддержания интереса
Re: Собеседование разработчика (альтернатива/дополнение)
6 мин
Не мог пройти мимо топика "Вопросы на собеседование middle/senior iOS Developer" и статьи "Собеседование разработчика". Хочу предложить альтернативный или дополнительный подход к собеседованию разработчиков.
Разбор говнокода или сотня разношерстных вопросов на листочке — это, конечно, прекрасно, но если это единственный этап собеседования, то это вызывает желание спросить что-то вроде: «Вы серьезно?»
Вы не устали от того, что на собеседованиях на конкретную позицию разработчика вас спрашивают достаточно сильно оторванную от жизни фигню, которую хочется поскорее забыть после такого собеседования (режим nightmare — это тест на 150+ вопросов и психолог в конце)? Я не отрицаю, что оценивать качество кода — это очень важно, но оценивать качество какого-то конкретного куска и делать по нему большие выводы — это точно неправильно.
К тому же, слишком много так называемых разработчиков не имеют никакого понятия о том, как строить архитектуру приложения, как грамотно разделить компоненты на модули, как внести гибкость для последующих изменений проекта. А вопросы подобные вопросам из топика "Вопросы на собеседование middle/senior iOS Developer" не дадут вам понять, насколько человек хорошо применяет свои знания при реализации проекта.
Давайте рассмотрим на примере android разработчика (адаптировать можно для любой области, но вы же понимаете, что без конкретики эту статью просто раскритиковали бы, так что поговорим об android).
Что я предлагаю: берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение и беседуем насчет того, как кандидат бы его сделал!
Почему это хороший вариант? Вы сможете достаточно точно оценить уровень разработчика в проектировании и реализации ПО, его знание платформы и другие важные вам ньюансы, а так же просто приятно провести время (в случае с компетентным кандидатом, да и ему будет интереснее чем на типичном собеседовании). + Вы сможете понять, насколько человек общителен, как вольется в вашу команду, сможет ли он объяснять свои решения другим?
Разбор листочка с кодом или заученные ответы на подковыристые вопросы не дадут вам понять, как потом этот человек справится с реальными задачами на реальном проекте (но я не говорю, что не надо спрашивать этого, можно, но это не должно быть основой собеседования).
Для примера, возьмем приложение Вконтакте для android (оно большое, сложное и многим знакомое).
Разбор говнокода или сотня разношерстных вопросов на листочке — это, конечно, прекрасно, но если это единственный этап собеседования, то это вызывает желание спросить что-то вроде: «Вы серьезно?»
Вы не устали от того, что на собеседованиях на конкретную позицию разработчика вас спрашивают достаточно сильно оторванную от жизни фигню, которую хочется поскорее забыть после такого собеседования (режим nightmare — это тест на 150+ вопросов и психолог в конце)? Я не отрицаю, что оценивать качество кода — это очень важно, но оценивать качество какого-то конкретного куска и делать по нему большие выводы — это точно неправильно.
К тому же, слишком много так называемых разработчиков не имеют никакого понятия о том, как строить архитектуру приложения, как грамотно разделить компоненты на модули, как внести гибкость для последующих изменений проекта. А вопросы подобные вопросам из топика "Вопросы на собеседование middle/senior iOS Developer" не дадут вам понять, насколько человек хорошо применяет свои знания при реализации проекта.
Что ты предлагаешь, чувак?
Давайте рассмотрим на примере android разработчика (адаптировать можно для любой области, но вы же понимаете, что без конкретики эту статью просто раскритиковали бы, так что поговорим об android).
Что я предлагаю: берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение и беседуем насчет того, как кандидат бы его сделал!
Почему это хороший вариант? Вы сможете достаточно точно оценить уровень разработчика в проектировании и реализации ПО, его знание платформы и другие важные вам ньюансы, а так же просто приятно провести время (в случае с компетентным кандидатом, да и ему будет интереснее чем на типичном собеседовании). + Вы сможете понять, насколько человек общителен, как вольется в вашу команду, сможет ли он объяснять свои решения другим?
Разбор листочка с кодом или заученные ответы на подковыристые вопросы не дадут вам понять, как потом этот человек справится с реальными задачами на реальном проекте (но я не говорю, что не надо спрашивать этого, можно, но это не должно быть основой собеседования).
Для примера, возьмем приложение Вконтакте для android (оно большое, сложное и многим знакомое).