#2018-06-04
Говорят сегодня Microsoft объявит о покупке Github. Несколько лет назад ни за что не поверил бы в это.
В последние годы финансовые дела у Github шли не очень хорошо, и, чтобы нормализоваться, им нужно либо выходить на IPO и привлекать инвестиции, либо объединиться с кем-то.
https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github
Говорят сегодня Microsoft объявит о покупке Github. Несколько лет назад ни за что не поверил бы в это.
В последние годы финансовые дела у Github шли не очень хорошо, и, чтобы нормализоваться, им нужно либо выходить на IPO и привлекать инвестиции, либо объединиться с кем-то.
https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github
# 2018-06-05
По следам WWDC 2018
Представим, что вы не смотрели ивент Apple, и хотите знать что же все-таки произошло. Редакция нашего уютного тамтамчика смотрела его для вас. Всю ночь.
Из важного:
- нотификации в iOS теперь группируются по приложениям (браво, мне этого не хватало в айфоне)
- утверждают, что перформанс в iOS будет "икс таймс бэттер" даже на старых устройствах
- красивая темная тема в macOS, которая динамически меняется (а-ля f.lux)
- конференс-колл в FaceTime с любопытным интерфейсом
- AR и ML бла бла бла
Из очень важного:
- уоки-токи на часах
- анимоджи, мемомоджи, мимимоджи и, судя по всему, Мимино
Tim Cook выполнял роль конферансье, а прайм тайм весь вечер занимал Craig Federighi. Со сцены его было не выгнать, как ребята ни старались.
Ну, и упомяну другие детали, о которых говорили со сцены:
Иснт ит эмэйзин?
Анбеливебл
Итс притти кул, йеа?
Супер иси ту сетап
Бреаксру
Соу мач фан
Зэтс хау симпл ит из
Итс рили фан
Зис ис зе фьюче
Лукс фантастик
Кастомерс ду лав ит
Греат нью фичерс
Инкредибл платформ
Комплитли иммерс ю
Зис ис рили осом
Инкредибл
Соу найс
Эмейзинг
Трули инкредибл
Лук энд саунд осом
Соу грейт
Хьюдж лип форвард
Джаст горджес
Соу кул
Джаст лук фэнтастик
Даснт ит лук эмейзин?
Хьюдж диференс
Кос итс олл билт ин свифт
Хай перформанс он девайс
Грейт нейтив апликейшнс
Фул эдветнтедж оф зэ пауэр
Эргономикс
Сник пик
Мохавэ
МОХАВЭ
М О Х А В Э
Ай хоуп ю лайк ит
Экстроординари морнинг
Нэкшт иеар
Хьюдж апдейт
Летс хэв инкредибл вик тугезэ
Пойду за мазью от диатеза. Оставайтесь с нами.
По следам WWDC 2018
Представим, что вы не смотрели ивент Apple, и хотите знать что же все-таки произошло. Редакция нашего уютного тамтамчика смотрела его для вас. Всю ночь.
Из важного:
- нотификации в iOS теперь группируются по приложениям (браво, мне этого не хватало в айфоне)
- утверждают, что перформанс в iOS будет "икс таймс бэттер" даже на старых устройствах
- красивая темная тема в macOS, которая динамически меняется (а-ля f.lux)
- конференс-колл в FaceTime с любопытным интерфейсом
- AR и ML бла бла бла
Из очень важного:
- уоки-токи на часах
- анимоджи, мемомоджи, мимимоджи и, судя по всему, Мимино
Tim Cook выполнял роль конферансье, а прайм тайм весь вечер занимал Craig Federighi. Со сцены его было не выгнать, как ребята ни старались.
Ну, и упомяну другие детали, о которых говорили со сцены:
Иснт ит эмэйзин?
Анбеливебл
Итс притти кул, йеа?
Супер иси ту сетап
Бреаксру
Соу мач фан
Зэтс хау симпл ит из
Итс рили фан
Зис ис зе фьюче
Лукс фантастик
Кастомерс ду лав ит
Греат нью фичерс
Инкредибл платформ
Комплитли иммерс ю
Зис ис рили осом
Инкредибл
Соу найс
Эмейзинг
Трули инкредибл
Лук энд саунд осом
Соу грейт
Хьюдж лип форвард
Джаст горджес
Соу кул
Джаст лук фэнтастик
Даснт ит лук эмейзин?
Хьюдж диференс
Кос итс олл билт ин свифт
Хай перформанс он девайс
Грейт нейтив апликейшнс
Фул эдветнтедж оф зэ пауэр
Эргономикс
Сник пик
Мохавэ
МОХАВЭ
М О Х А В Э
Ай хоуп ю лайк ит
Экстроординари морнинг
Нэкшт иеар
Хьюдж апдейт
Летс хэв инкредибл вик тугезэ
Пойду за мазью от диатеза. Оставайтесь с нами.
# 2018-06-14
В мире лицензий на программные продукты (MIT, Apache-2.0, GPL-3, LGPL-3.0) набирает популярность новый игрок GLWTPL:
"When I wrote this, only God and I understood what I was doing. Now, only God knows."
Этот канал теперь имеет официальную лицензию. This project is licensed under GLWTPL.
https://github.com/me-shaon/GLWTPL
В мире лицензий на программные продукты (MIT, Apache-2.0, GPL-3, LGPL-3.0) набирает популярность новый игрок GLWTPL:
"When I wrote this, only God and I understood what I was doing. Now, only God knows."
Этот канал теперь имеет официальную лицензию. This project is licensed under GLWTPL.
https://github.com/me-shaon/GLWTPL
# 2018-06-15
WhatsApp будет поддерживать Android Gingerbread 2.3 до 2020. Согласно статистике Google таких устройств сейчас всего 0,3%. С учётом выхода этой версии Android в 2010-м году – это ни много ни мало десять лет. https://m.androidcentral.com/whatsapp-will-continue-work-android-gingerbread-until-2020
В целом при правильно спроектированном приложении и наличии ресурсов это не так сложно. Даже некий тренд наметился – делать полноценную версию приложения для крутых hi-end устройств и low-end версию для слабых устройств.
Android One как раз про слабые устройства для развивающихся рынков. А теперь ещё и инициатива с Android Go. В Google сейчас как раз переписывают свои основные приложения в таком ключе: YouTube Go, Google Maps Go, Gmail Go, Gboard Go, Google Play Store, Chrome, Files Go. Они будут простые, но быстрые и нетребовательные к ресурсам.
https://www.android.com/versions/oreo-8-0/go-edition/
Интересные факты:
- в 2015 в команде WhatsApp было 55 инженеров на 900 миллионов пользователей
- на конец 2017 около 200 человек на 1,5 миллиарда пользователей
- в Facebook на конец 2017 было 25000 сотрудников
- у WhatsApp есть отдельное приложение для бизнеса с автоматизацией и статистикой https://www.whatsapp.com/business/
WhatsApp будет поддерживать Android Gingerbread 2.3 до 2020. Согласно статистике Google таких устройств сейчас всего 0,3%. С учётом выхода этой версии Android в 2010-м году – это ни много ни мало десять лет. https://m.androidcentral.com/whatsapp-will-continue-work-android-gingerbread-until-2020
В целом при правильно спроектированном приложении и наличии ресурсов это не так сложно. Даже некий тренд наметился – делать полноценную версию приложения для крутых hi-end устройств и low-end версию для слабых устройств.
Android One как раз про слабые устройства для развивающихся рынков. А теперь ещё и инициатива с Android Go. В Google сейчас как раз переписывают свои основные приложения в таком ключе: YouTube Go, Google Maps Go, Gmail Go, Gboard Go, Google Play Store, Chrome, Files Go. Они будут простые, но быстрые и нетребовательные к ресурсам.
https://www.android.com/versions/oreo-8-0/go-edition/
Интересные факты:
- в 2015 в команде WhatsApp было 55 инженеров на 900 миллионов пользователей
- на конец 2017 около 200 человек на 1,5 миллиарда пользователей
- в Facebook на конец 2017 было 25000 сотрудников
- у WhatsApp есть отдельное приложение для бизнеса с автоматизацией и статистикой https://www.whatsapp.com/business/
# 2018-06-20
Airbnb в свое время была одной из первых компаний, кто стал серьезно использовать ReactNative в продакшн – фреймворк кросс-платформенной мобильной разработки от Facebook.
Буквально вчера они выпустили серию коротких статей, где говорят, что отказываются от этого фреймворка в пользу нативной разработки по ряду причин. Но при этом не оставляют утопичных мыслей о единой кодовой базе для нескольких платформ, намекая на Flutter-подобные фреймворки.
https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c
Airbnb в свое время была одной из первых компаний, кто стал серьезно использовать ReactNative в продакшн – фреймворк кросс-платформенной мобильной разработки от Facebook.
Буквально вчера они выпустили серию коротких статей, где говорят, что отказываются от этого фреймворка в пользу нативной разработки по ряду причин. Но при этом не оставляют утопичных мыслей о единой кодовой базе для нескольких платформ, намекая на Flutter-подобные фреймворки.
https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c
# 2018-06-22
Вот вам вся правда про иерархию разработчиков в Google (и не только), прямо со дна пищевой цепочки. Единственный, наверное, кого это не касается, Джейк наш 'Lord and Savior' Уортон.
At Google, most engineers are too snooty to do mobile or web programming. “I don’t do frontend”, they proclaim with maximal snootiness. There’s a phenomenon there that I like to call the “DAG of Disdain”, wherein DAG means Directed Acyclic Graph, which is a bit like a flowchart. At the top of Snoot Mountain sit the lofty Search engineers writing in C++, which is considered cooler than Java, which is cooler than Python, which is cooler than JavaScript. And Search is cooler than Ads, which is cooler than Apps, which is cooler than Tools, which is cooler than Frontends. And so on. Programmers love to look down on each other. And if you’re unlucky enough to be a Google mobile engineer, you’re stuck scuffling around at the bottom of several totem poles with everyone looking down on you.
И в целом довольно интересная статья от Steve Yegge про будущее Android. Он какое-то время работал в Google и имеет свое виденье происходящего.
whttps://medium.com/@steve.yegge/who-will-steal-android-from-google-af3622b6252e
Вот вам вся правда про иерархию разработчиков в Google (и не только), прямо со дна пищевой цепочки. Единственный, наверное, кого это не касается, Джейк наш 'Lord and Savior' Уортон.
At Google, most engineers are too snooty to do mobile or web programming. “I don’t do frontend”, they proclaim with maximal snootiness. There’s a phenomenon there that I like to call the “DAG of Disdain”, wherein DAG means Directed Acyclic Graph, which is a bit like a flowchart. At the top of Snoot Mountain sit the lofty Search engineers writing in C++, which is considered cooler than Java, which is cooler than Python, which is cooler than JavaScript. And Search is cooler than Ads, which is cooler than Apps, which is cooler than Tools, which is cooler than Frontends. And so on. Programmers love to look down on each other. And if you’re unlucky enough to be a Google mobile engineer, you’re stuck scuffling around at the bottom of several totem poles with everyone looking down on you.
И в целом довольно интересная статья от Steve Yegge про будущее Android. Он какое-то время работал в Google и имеет свое виденье происходящего.
whttps://medium.com/@steve.yegge/who-will-steal-android-from-google-af3622b6252e
# 2018-06-28
Зарисовка "Интервью rockstar программиста".
И мне нравится формулировка от Nate Waddoups:
Junior Engineer - creates complex solutions to simple problems.
Engineer - creates simple solutions to simple problems.
Senior Engineer - creates simple solutions to complex problems.
Rockstar Engineer - makes complex problems disappear.
Зарисовка "Интервью rockstar программиста".
И мне нравится формулировка от Nate Waddoups:
Junior Engineer - creates complex solutions to simple problems.
Engineer - creates simple solutions to simple problems.
Senior Engineer - creates simple solutions to complex problems.
Rockstar Engineer - makes complex problems disappear.
# 2018-09-16
Я уже упоминал любопытное видение будущего Android в статье Steve Yegge (https://tt.me/melnikov/AWQmKSGOM3M), но недавно наткнулся на еще более провокационную статью от Vasiliy Zukanov.
Он довольно известный блоггер в индустрии и написал не просто статью, а сделал целую подборку материалов с анализом текущего положения дел. При этом пришел к выводу о существовании теории заговора со стороны Google.
Если кратко, то от жадности Google может убить Android. При этом есть предпосылки того, что они разрабатывают технологии для подобного исхода событий. Имеется в виду lawsuit с Oracle, в результате которого Google придется делиться прибылью. При этом в сюжете фигурируют Kotlin, Flutter, Project Treble и операционная система Fuchsia от Google.
Читается как детективный роман https://www.techyourchance.com/will-google-betray-kill-android/
Я уже упоминал любопытное видение будущего Android в статье Steve Yegge (https://tt.me/melnikov/AWQmKSGOM3M), но недавно наткнулся на еще более провокационную статью от Vasiliy Zukanov.
Он довольно известный блоггер в индустрии и написал не просто статью, а сделал целую подборку материалов с анализом текущего положения дел. При этом пришел к выводу о существовании теории заговора со стороны Google.
Если кратко, то от жадности Google может убить Android. При этом есть предпосылки того, что они разрабатывают технологии для подобного исхода событий. Имеется в виду lawsuit с Oracle, в результате которого Google придется делиться прибылью. При этом в сюжете фигурируют Kotlin, Flutter, Project Treble и операционная система Fuchsia от Google.
Читается как детективный роман https://www.techyourchance.com/will-google-betray-kill-android/
# 2018-10-18
В честь закрытия Google+ история давно минувших дней (2008-2014), но не потерявшая своей остроты.
https://twitter.com/morganknutson/status/1049523067506966529
Удивительное повествование от дизайнера Morgan Knutson из Google. Во-первых, это первая в истории Twitter-книга мемуаров; во-вторых, интересные подробности о работе в Google.
Он был дизайнером в ряде некоммерческих организаций, и, когда обзавелся семьей, решил, что надо больше зарабатывать. Начал постить на dribbble и искать новое место. Через какое-то время на него вышли рекрутеры Google, позвали на собеседование в команду Chrome. И вроде он успешно прошел его, но 4 месяца с ним не связывались.
Через 4 месяца его взяли, он был счастлив. Но в первый же день ему сообщили, что работать он будет над Google+.
Fuck. “Whatever”, I thought, “I’ll just do my best and move to Chrome or something cooler after a while” Heh, so naive.
Оказалось, один из дизайнеров на собеседовании был из G+ команды и приложил усилия, чтобы он попал к ним. "Вот здорово!" подумал Morgan.
Работать он стал в главном здании офиса в MV и имел доступ к этажу (!!!) Ларри Пейджа, наравне с командой G+. Такой блат был за счет лоббирования Vic Gundotra (SVP G+ на тот момент).
Он сидел недалеко от Моргана, но при этом Gundontra ни разу с ним не поздоровался за все время их совместной работы (8 месяцев), зато он постоянно ходил флиртовать с девушками из их команды.
Vic был довольно влиятельным в Google. Он выбил такие условия, что все команды, кто интегрирует себе G+ фичи, получат коэффициент 1.5-3 к ежегодному бонусу.
А бонус и так был около 15% от ежегодного оклада. Никому это было ненужно и неинтересно, но ради денег все ринулись интегрировать API G+.
У Vic'а были и другие "здравые" идеи. Например, редизайнить продукт с нуля каждые 6 месяцев. В итоге в 2014 он покинул пост.
И еще много-много других заметок: про зарплату, про другие команды, Hangouts, про его идеи, которые несколько раз были присвоены другими людьми, о сроках и прочем.
Многое ему в Google не нравилось. В итоге он покинул компанию с облегчением, но при этом с сожалением о людях и специалистах, которые там работают. Ушел в Dropbox, где ему нравилось и было комфортно во всех отношениях (только sign bonus был как все бонусы в Google за 4 года). Далее он сделал стартап Shift https://shift.com/home (140M $ в sereies D), а сейчас работает в другом проекте.
Интересно почитать.
В честь закрытия Google+ история давно минувших дней (2008-2014), но не потерявшая своей остроты.
https://twitter.com/morganknutson/status/1049523067506966529
Удивительное повествование от дизайнера Morgan Knutson из Google. Во-первых, это первая в истории Twitter-книга мемуаров; во-вторых, интересные подробности о работе в Google.
Он был дизайнером в ряде некоммерческих организаций, и, когда обзавелся семьей, решил, что надо больше зарабатывать. Начал постить на dribbble и искать новое место. Через какое-то время на него вышли рекрутеры Google, позвали на собеседование в команду Chrome. И вроде он успешно прошел его, но 4 месяца с ним не связывались.
Через 4 месяца его взяли, он был счастлив. Но в первый же день ему сообщили, что работать он будет над Google+.
Fuck. “Whatever”, I thought, “I’ll just do my best and move to Chrome or something cooler after a while” Heh, so naive.
Оказалось, один из дизайнеров на собеседовании был из G+ команды и приложил усилия, чтобы он попал к ним. "Вот здорово!" подумал Morgan.
Работать он стал в главном здании офиса в MV и имел доступ к этажу (!!!) Ларри Пейджа, наравне с командой G+. Такой блат был за счет лоббирования Vic Gundotra (SVP G+ на тот момент).
Он сидел недалеко от Моргана, но при этом Gundontra ни разу с ним не поздоровался за все время их совместной работы (8 месяцев), зато он постоянно ходил флиртовать с девушками из их команды.
Vic был довольно влиятельным в Google. Он выбил такие условия, что все команды, кто интегрирует себе G+ фичи, получат коэффициент 1.5-3 к ежегодному бонусу.
А бонус и так был около 15% от ежегодного оклада. Никому это было ненужно и неинтересно, но ради денег все ринулись интегрировать API G+.
У Vic'а были и другие "здравые" идеи. Например, редизайнить продукт с нуля каждые 6 месяцев. В итоге в 2014 он покинул пост.
И еще много-много других заметок: про зарплату, про другие команды, Hangouts, про его идеи, которые несколько раз были присвоены другими людьми, о сроках и прочем.
Многое ему в Google не нравилось. В итоге он покинул компанию с облегчением, но при этом с сожалением о людях и специалистах, которые там работают. Ушел в Dropbox, где ему нравилось и было комфортно во всех отношениях (только sign bonus был как все бонусы в Google за 4 года). Далее он сделал стартап Shift https://shift.com/home (140M $ в sereies D), а сейчас работает в другом проекте.
Интересно почитать.
# 2018-10-20
Посмотрел на Progressive Web App (PWA) – технологию от Google, которая позволяет мобильному вебу иметь кеш, работу в фоне, пуши и прочие преимущества нативных приложений.
Посмотрел на примеры реализаций https://pwa.rocks и увидел среди прочих http://web.telegram.org Удивился, открыл. Страничка предложила добавить ярлык на рабочий стол. В итоге в списке приложений телефона появилась иконка Telegram, которая открывает браузер, но выглядит как нативное приложение. То есть даже сложные приложение, как, например, мессенджер может вполне работать как PWA на мобильном.
Конечно, есть недостатки – Edge, IE и Safari пока не поддерживают технологию, но есть и достоинства, ставить приложения многие не хотят, а такую богатую страничку посещать одно удовольствие.
Ну, и супер эффект достигается, когда PWA идет с AMP ;)
Внятный обзор PWA https://medium.com/@deepusnath/4-points-to-keep-in-mind-before-introducing-progressive-web-apps-pwa-to-your-team-8dc66bcf6011
Посмотрел на Progressive Web App (PWA) – технологию от Google, которая позволяет мобильному вебу иметь кеш, работу в фоне, пуши и прочие преимущества нативных приложений.
Посмотрел на примеры реализаций https://pwa.rocks и увидел среди прочих http://web.telegram.org Удивился, открыл. Страничка предложила добавить ярлык на рабочий стол. В итоге в списке приложений телефона появилась иконка Telegram, которая открывает браузер, но выглядит как нативное приложение. То есть даже сложные приложение, как, например, мессенджер может вполне работать как PWA на мобильном.
Конечно, есть недостатки – Edge, IE и Safari пока не поддерживают технологию, но есть и достоинства, ставить приложения многие не хотят, а такую богатую страничку посещать одно удовольствие.
Ну, и супер эффект достигается, когда PWA идет с AMP ;)
Внятный обзор PWA https://medium.com/@deepusnath/4-points-to-keep-in-mind-before-introducing-progressive-web-apps-pwa-to-your-team-8dc66bcf6011
# 2018-11-15
Недавно на Hacker News один из сотрудников Google ответил почему качество софта в компании местами очень посредственное.
Если кратко, то дело в том, что самый простой способ получить promotion – это сделать большой публичный запуск. А за правку багов и за педантичное улучшение продукта ничего кроме мазолей и плохого настроения не получить.
https://news.ycombinator.com/item?id=18379050
Очень похоже на мнение бывшего сотрудника G+, о котором я писал.
Недавно на Hacker News один из сотрудников Google ответил почему качество софта в компании местами очень посредственное.
Если кратко, то дело в том, что самый простой способ получить promotion – это сделать большой публичный запуск. А за правку багов и за педантичное улучшение продукта ничего кроме мазолей и плохого настроения не получить.
https://news.ycombinator.com/item?id=18379050
Очень похоже на мнение бывшего сотрудника G+, о котором я писал.
Media is too big
VIEW IN TELEGRAM
# 2018-12-17
Пока вы пишите ваши старомодные мобильные приложения на Android и iOS, ваши конкуренты пишут в 2 раза больше на Flutter, Kotlin, а возможно и на, прости Господи, ReactNative.
Инициатива Kotlin Native заключается в компиляции языка в native binaries посредством LLVM. Можно шарить исходники моделек, логику и прочие независимые от платформы вещи, и радоваться тому, что не надо писать дважды. Прямо сейчас в подземельях JetBrains как раз допиливают тулинг, чтобы все работало и к тому же более-менее быстро. Уже сейчас вы можете поиграться с компиляцией в ObjC, как я понимаю.
Две недели, как Flutter официально зарелизили до стабильной версии 1.0. Там все работает немного иначе: код из Dart VM компилируется в машинный код, но при этом работает платформа, как в игровым движке. То есть на GL разработчики Google реализовали виджеты, которые на Android выглядят, как Material, а на iOS в Cupertino стиле. И, как вы понимаете, ничего не остановит их от того, чтобы сделать веб-версию. Примечательно, что при
Пока вы пишите ваши старомодные мобильные приложения на Android и iOS, ваши конкуренты пишут в 2 раза больше на Flutter, Kotlin, а возможно и на, прости Господи, ReactNative.
Инициатива Kotlin Native заключается в компиляции языка в native binaries посредством LLVM. Можно шарить исходники моделек, логику и прочие независимые от платформы вещи, и радоваться тому, что не надо писать дважды. Прямо сейчас в подземельях JetBrains как раз допиливают тулинг, чтобы все работало и к тому же более-менее быстро. Уже сейчас вы можете поиграться с компиляцией в ObjC, как я понимаю.
Две недели, как Flutter официально зарелизили до стабильной версии 1.0. Там все работает немного иначе: код из Dart VM компилируется в машинный код, но при этом работает платформа, как в игровым движке. То есть на GL разработчики Google реализовали виджеты, которые на Android выглядят, как Material, а на iOS в Cupertino стиле. И, как вы понимаете, ничего не остановит их от того, чтобы сделать веб-версию. Примечательно, что при
# 2018-12-26
Прежде чем пользоваться современным веб-сайтом, вы должны:
- закрыть инфомацию о cookies
- закрыть онлайн-ассистента
- закрыть подтверждение местоположения
- закрыть предложение о подписке на newsletter
- заблокировать запрос нотификаций "о самом важном"
- закрыть специальное предложение
Отдельный котел в аду должен быть для тех, кто отрисовывает часть контента, а потом догружает что-то и сдвигает большинство элементов. Прицеливаешься, а оно "вжик" и переместилось.
С ними рядом мракобесы, которые делают крохотные элементы переключения в пейджинге. Попасть в них могут разве что снайперы. Не говоря уже о том, что хорошо бы иметь опцию "покажи все", ну или "покажи много", чтобы не играть в пейджинг-снайпера.
А во главе этого демонического шествия настойчивые просьбы оценить приложение.
Вот вам икона Никиты Бесогона в качестве оберега.
P.S.: Да, канал Михалкова на Youtube называется в честь святого великомученика https://ru.m.wikipedia.org/wiki/Никита_Бесогон
Прежде чем пользоваться современным веб-сайтом, вы должны:
- закрыть инфомацию о cookies
- закрыть онлайн-ассистента
- закрыть подтверждение местоположения
- закрыть предложение о подписке на newsletter
- заблокировать запрос нотификаций "о самом важном"
- закрыть специальное предложение
Отдельный котел в аду должен быть для тех, кто отрисовывает часть контента, а потом догружает что-то и сдвигает большинство элементов. Прицеливаешься, а оно "вжик" и переместилось.
С ними рядом мракобесы, которые делают крохотные элементы переключения в пейджинге. Попасть в них могут разве что снайперы. Не говоря уже о том, что хорошо бы иметь опцию "покажи все", ну или "покажи много", чтобы не играть в пейджинг-снайпера.
А во главе этого демонического шествия настойчивые просьбы оценить приложение.
Вот вам икона Никиты Бесогона в качестве оберега.
P.S.: Да, канал Михалкова на Youtube называется в честь святого великомученика https://ru.m.wikipedia.org/wiki/Никита_Бесогон
# 2019-08-15
В поисках Святого Грааля
Сегодня только ленивый не мечтает о том, чтобы сэкономить ресурсы и время на создании ПО, а один из самых очевидных способов - кросплатформенная разработка клиентов. Многие ищут этот философский камень, чтобы превратить две, а то и три команды, дублирующие друг друга, в одну.
Еще одна компания заявила, что хочет отказаться от подобного подхода к клиентской разработке. В прошлый раз мы слушали исповедь Airbnb о React Native. На этот раз Dropbox поделился результатами своего видения кросплатформенности.
https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android/
tl;dr: пробовали общие вещи написать на C++, но столкнулись с оверхедом в разработке, отсутствием необходимого тулинга, разница в платформах докатилось и до общей C++ библиотеки, проблемы с хайрингом и экспертизой (многие просто не хотят писать на C++ и я их не осуждаю). В итоге все бонусы от переиспользования фактически сведены на нет.
Вообще сейчас существует несколько основных подходов к кросплатфоменности в клиентской разработке:
- Phonegap/Xamarin и подобные
Позволяют писать а-ля веб приложения и рендерят их с помощью своего движка. Самый бородатый из подходов, у которого основная проблемы в "не нативном" виде UI и в сложностях поддержки нативных компонент (взаимодействие с платформой). Про минусы этого подхода очень много информации в сети.
- логика на C++ с прокинутыми вызовами для платформенного UI.
Такой подход использует Telegram, судя по коду клиентов. Сетевой клиент и логика написаны таким образом. Но похоже, что Telegram делал это не чтобы сэкономить на разработке, а чтобы иметь стабильный и отлаженный компонент для своего протокола.
Про минусы этого подхода вчера написал Dropbox в своей статье.
- React Native
Превращают js-код в нативный код платформ. Про него нелестно отозвался Airbnb, о чем я уже упоминал https://tt.me/melnikov/AWQecGaFIIk
- Flutter
Разработанный Google фреймворк позволяет писать приложения на языке Dart, который рендерит UI не нативными средствами платформы, а своим способом, написанным на C++, подобно игровым движкам.
Никто из больших игроков пока еще не пробовал этот подход насколько мне известно. Все боятся, потому что отсутствует тулинг, все наработки надо писать заново, да и в целом инфраструктура сыровата. Но Google продолжает активно развивать этот подход
- Kotlin Native
Инициатива JetBrains иметь нативный платформенный код для UI, но общую логику на Kotlin, которая может быть скомпилирована в Java-байткод или нативно с помощью LLVM.
С этим подходом проблема в том, что шарится только логика, хотя UI, как правило, тоже отнимает много сил, и нельзя использовать привычные библиотеки при разработке логики (только Kotlin Native friednly), чтобы они могли использоваться на разных платформах. Плюс также пока очень сырой тулинг.
В поисках Святого Грааля
Сегодня только ленивый не мечтает о том, чтобы сэкономить ресурсы и время на создании ПО, а один из самых очевидных способов - кросплатформенная разработка клиентов. Многие ищут этот философский камень, чтобы превратить две, а то и три команды, дублирующие друг друга, в одну.
Еще одна компания заявила, что хочет отказаться от подобного подхода к клиентской разработке. В прошлый раз мы слушали исповедь Airbnb о React Native. На этот раз Dropbox поделился результатами своего видения кросплатформенности.
https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android/
tl;dr: пробовали общие вещи написать на C++, но столкнулись с оверхедом в разработке, отсутствием необходимого тулинга, разница в платформах докатилось и до общей C++ библиотеки, проблемы с хайрингом и экспертизой (многие просто не хотят писать на C++ и я их не осуждаю). В итоге все бонусы от переиспользования фактически сведены на нет.
Вообще сейчас существует несколько основных подходов к кросплатфоменности в клиентской разработке:
- Phonegap/Xamarin и подобные
Позволяют писать а-ля веб приложения и рендерят их с помощью своего движка. Самый бородатый из подходов, у которого основная проблемы в "не нативном" виде UI и в сложностях поддержки нативных компонент (взаимодействие с платформой). Про минусы этого подхода очень много информации в сети.
- логика на C++ с прокинутыми вызовами для платформенного UI.
Такой подход использует Telegram, судя по коду клиентов. Сетевой клиент и логика написаны таким образом. Но похоже, что Telegram делал это не чтобы сэкономить на разработке, а чтобы иметь стабильный и отлаженный компонент для своего протокола.
Про минусы этого подхода вчера написал Dropbox в своей статье.
- React Native
Превращают js-код в нативный код платформ. Про него нелестно отозвался Airbnb, о чем я уже упоминал https://tt.me/melnikov/AWQecGaFIIk
- Flutter
Разработанный Google фреймворк позволяет писать приложения на языке Dart, который рендерит UI не нативными средствами платформы, а своим способом, написанным на C++, подобно игровым движкам.
Никто из больших игроков пока еще не пробовал этот подход насколько мне известно. Все боятся, потому что отсутствует тулинг, все наработки надо писать заново, да и в целом инфраструктура сыровата. Но Google продолжает активно развивать этот подход
- Kotlin Native
Инициатива JetBrains иметь нативный платформенный код для UI, но общую логику на Kotlin, которая может быть скомпилирована в Java-байткод или нативно с помощью LLVM.
С этим подходом проблема в том, что шарится только логика, хотя UI, как правило, тоже отнимает много сил, и нельзя использовать привычные библиотеки при разработке логики (только Kotlin Native friednly), чтобы они могли использоваться на разных платформах. Плюс также пока очень сырой тулинг.
# 2019-12-04
Иногда вам хочется посетить какой-нибудь запрещенный сайт. Это может быть LinkedIn, Lurkmore, RuTracker или еще какой. В зависимости от провайдера не все сайты могут открыться. Не так давно сокращатель ссылок bitly.com был тоже заблокирован.
Это происходит из-за Федерального закона от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
Чтобы все же посетить данные сайты вам нужен VPN, но все приличные сервисы стоят денег, а платить 2 тысячи в год за редкие заходы на запрещенные сайты не хочется.
Установите себе браузер Opera. Он имеет встроенный VPN, который нужно включить в настройках (большой тумблер вкл/выкл). Когда ваш обычный браузер не попадет на очередной сайт из-за блокировок, просто откройте Opera и заходите через нее.
Иногда вам хочется посетить какой-нибудь запрещенный сайт. Это может быть LinkedIn, Lurkmore, RuTracker или еще какой. В зависимости от провайдера не все сайты могут открыться. Не так давно сокращатель ссылок bitly.com был тоже заблокирован.
Это происходит из-за Федерального закона от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
Чтобы все же посетить данные сайты вам нужен VPN, но все приличные сервисы стоят денег, а платить 2 тысячи в год за редкие заходы на запрещенные сайты не хочется.
Установите себе браузер Opera. Он имеет встроенный VPN, который нужно включить в настройках (большой тумблер вкл/выкл). Когда ваш обычный браузер не попадет на очередной сайт из-за блокировок, просто откройте Opera и заходите через нее.
# 2019-12-05
JetBrains представила Space ‒ продукт для облегчения коллективной разработки проектов.
https://www.jetbrains.com/space
Фактически это Jira на стероидах или "швейцарский нож" для разработки:
- рабочие чаты
- календарь
- вики
- трекер задач
- блоги
- контроль версий
- CI/CD
- artifactory и docker registry (и package management в целом, включая distibution)
Может быть cloud или hosted. Для маленьких cloud бесплатно.
То, что сейчас показано на сайте и в превьюшках/скринах, выглядит очень круто.
На перезентации сказали, что есть мобильные приложения, которые написаны на Kotlin/Multiplatform. То есть вся логика у них шарится (JS/iOS/Android).
JetBrains представила Space ‒ продукт для облегчения коллективной разработки проектов.
https://www.jetbrains.com/space
Фактически это Jira на стероидах или "швейцарский нож" для разработки:
- рабочие чаты
- календарь
- вики
- трекер задач
- блоги
- контроль версий
- CI/CD
- artifactory и docker registry (и package management в целом, включая distibution)
Может быть cloud или hosted. Для маленьких cloud бесплатно.
То, что сейчас показано на сайте и в превьюшках/скринах, выглядит очень круто.
На перезентации сказали, что есть мобильные приложения, которые написаны на Kotlin/Multiplatform. То есть вся логика у них шарится (JS/iOS/Android).
# 2020-01-16
JetBrains сделали шрифт специально для разработки. Осовременели и эту область. В нем все прекрасно: и продуман для долгой работы с текстом, и выглядит хорошо, и лигатуры есть.
Я до этого использовал везде Fira Code, но этот приятней.
https://www.jetbrains.com/lp/mono/
https://blog.jetbrains.com/blog/2020/01/15/jetbrains-mono-a-new-font-made-for-developers/
JetBrains сделали шрифт специально для разработки. Осовременели и эту область. В нем все прекрасно: и продуман для долгой работы с текстом, и выглядит хорошо, и лигатуры есть.
Я до этого использовал везде Fira Code, но этот приятней.
https://www.jetbrains.com/lp/mono/
https://blog.jetbrains.com/blog/2020/01/15/jetbrains-mono-a-new-font-made-for-developers/
# 2020-02-05
Мне очень нравится "Дзэн" языка программирования Python. В какой-то момент он стал настолько популярен, что даже вошел в сам интерпритатор в виде вызова 'import this'.
"Дзэн" состоит из принципов, которыми руководствовались при разработке языка. Но они настолько универсальны, что, кажется, подходят вообще для всего. Слегка изменив пару формулировок, можно приписать их к любому жизненному процессу.
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
А написал его один из основных контрибуторов языка ‒ Tim Peters.
Мне очень нравится "Дзэн" языка программирования Python. В какой-то момент он стал настолько популярен, что даже вошел в сам интерпритатор в виде вызова 'import this'.
"Дзэн" состоит из принципов, которыми руководствовались при разработке языка. Но они настолько универсальны, что, кажется, подходят вообще для всего. Слегка изменив пару формулировок, можно приписать их к любому жизненному процессу.
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
А написал его один из основных контрибуторов языка ‒ Tim Peters.
Фундаментальное введение в stuctured concurrency
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
Статья показывает мысль программиста с 50-х годов прошлого века по наши дни: о важности flow control и как менялись парадигмы; как Дейкстра объявил войну goto, а Кнут наоборот заступался.
Подобные "black box rule" требования к flow control можно спроецировать на concurrency. В итоге приходим к подобию CoroutineContext в Kotlin и получаем простой и понятный механизм cancellation и error handling.
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
Статья показывает мысль программиста с 50-х годов прошлого века по наши дни: о важности flow control и как менялись парадигмы; как Дейкстра объявил войну goto, а Кнут наоборот заступался.
Подобные "black box rule" требования к flow control можно спроецировать на concurrency. В итоге приходим к подобию CoroutineContext в Kotlin и получаем простой и понятный механизм cancellation и error handling.