Инстаграм не стал дожидаться, пока Apple выкатит на iOS функциональность ограничения времени зависания в аппах, и запускает аналогичную сам.
Вполне вероятно, эта фича потом перейдёт в приложение Фейсбука. Ну и конечно красивый ход во всех отношениях — Инстаграм предлагает уведомление о превышении лимита, а не блокировку приложения и необходимость совершать какие-то действия.
Вполне вероятно, эта фича потом перейдёт в приложение Фейсбука. Ну и конечно красивый ход во всех отношениях — Инстаграм предлагает уведомление о превышении лимита, а не блокировку приложения и необходимость совершать какие-то действия.
Если вашего макбука про топовой конфигурации тоже не хватает, чтобы комфортно сидеть в слэке, появилась консольная альтернатива!
Очень клёвый формат — «Что нового в PHP 7.3 за 30 секунд в виде диффов».
https://www.tomasvotruba.cz/blog/2018/08/16/whats-new-in-php-73-in-30-seconds-in-diffs/
https://www.tomasvotruba.cz/blog/2018/08/16/whats-new-in-php-73-in-30-seconds-in-diffs/
По сравнению с этим хаком считаю, что у нас нет вообще никакого хардкода в проекте.
https://twitter.com/_inside/status/1035319938641276928
https://twitter.com/_inside/status/1035319938641276928
Twitter
Guilherme Rambo
The Apple Watch pride face is hardcoded to not show up if the paired iPhone is using the Russian locale
Менеджмент спецпроектов
Наши коммерческие спецпроекты — это микропроекты с очень коротким жизненным циклом: они разрабатываются, запускаются, какое-то время работают и закрываются.
Наши спецпроекты бывают простые в разработке и сложные, чаще всего это определяется сложностью бэкенда. И в спецпроектах любого типа и уровня сложности мы иногда косячим. Бывает, что успеваем поправить, и никто не замечает, а бывает и так, что приходится идти к клиенту и извиняться за свой промах. Из своего опыта мы выделили несколько правил, которые, я надеюсь, помогут нам (и вам) избежать некоторых проблем.
1. Не браться за проект, если времени не хватает, а дедлайн несдвигаемый. Иначе может быть так, что вы будете запускаться с серьёзными багами — отменить запуск невозможно, а ответственность слишком большая.
2. Полностью логгировать все присылаемые пользователем данные — регистрационные, ответы, клики, в общем всё, что можно потом использовать в случае, если данные в основном хранилище пропадут или будут испорчены. Однажды мы очистили хранилище на продакшене после запуска коммерческого спецпроекта, даже просто лог всех POST-запросов нас бы спас.
3. Не лениться прописывать все исключения и логгировать все ошибки и исключительные ситуации. Да, это одноразовый код. Нет, не надо экономить время на этом.
4. При запуске спецпроекта обязательно в рабочем режиме должен быть кто-то из разработчиков — следить за логами, ошибками и багрепортами. Однажды мы запустились в выходной без дежурного разработчика, считая, что всё достаточно протестировано. Это был тяжёлый опыт.
5. Прописывание универсальных чек-листов для запуска и окончания спецпроекта: очистить тестовые данные, проверить шериг в соцсети, прекратить приём заявок и так далее — ведь нельзя ничего пропустить.
6. У каждого проекта должен быть только один ответственный, но не для того, чтобы повесить всех собак на него в случае промаха, а для того, чтобы не было ситуаций типа «я думал, что ты это проконтролируешь».
7. Да, это маленькие проекты и темпы их разработки сильно отличаются («в такие дни я деплою на продакшн по 50 раз в сутки»), но это не значит, что моно ограничиться мессенджером для фиксирования задач — нужно вести список в Jira, Trello или хотя бы в гугл доке — чтобы ничего не потерялось, потому что каждый запуск нового минипроекта — это жара.
Наши коммерческие спецпроекты — это микропроекты с очень коротким жизненным циклом: они разрабатываются, запускаются, какое-то время работают и закрываются.
Наши спецпроекты бывают простые в разработке и сложные, чаще всего это определяется сложностью бэкенда. И в спецпроектах любого типа и уровня сложности мы иногда косячим. Бывает, что успеваем поправить, и никто не замечает, а бывает и так, что приходится идти к клиенту и извиняться за свой промах. Из своего опыта мы выделили несколько правил, которые, я надеюсь, помогут нам (и вам) избежать некоторых проблем.
1. Не браться за проект, если времени не хватает, а дедлайн несдвигаемый. Иначе может быть так, что вы будете запускаться с серьёзными багами — отменить запуск невозможно, а ответственность слишком большая.
2. Полностью логгировать все присылаемые пользователем данные — регистрационные, ответы, клики, в общем всё, что можно потом использовать в случае, если данные в основном хранилище пропадут или будут испорчены. Однажды мы очистили хранилище на продакшене после запуска коммерческого спецпроекта, даже просто лог всех POST-запросов нас бы спас.
3. Не лениться прописывать все исключения и логгировать все ошибки и исключительные ситуации. Да, это одноразовый код. Нет, не надо экономить время на этом.
4. При запуске спецпроекта обязательно в рабочем режиме должен быть кто-то из разработчиков — следить за логами, ошибками и багрепортами. Однажды мы запустились в выходной без дежурного разработчика, считая, что всё достаточно протестировано. Это был тяжёлый опыт.
5. Прописывание универсальных чек-листов для запуска и окончания спецпроекта: очистить тестовые данные, проверить шериг в соцсети, прекратить приём заявок и так далее — ведь нельзя ничего пропустить.
6. У каждого проекта должен быть только один ответственный, но не для того, чтобы повесить всех собак на него в случае промаха, а для того, чтобы не было ситуаций типа «я думал, что ты это проконтролируешь».
7. Да, это маленькие проекты и темпы их разработки сильно отличаются («в такие дни я деплою на продакшн по 50 раз в сутки»), но это не значит, что моно ограничиться мессенджером для фиксирования задач — нужно вести список в Jira, Trello или хотя бы в гугл доке — чтобы ничего не потерялось, потому что каждый запуск нового минипроекта — это жара.
Установил бету iOS 12.
Ожидание: стал меньше проводить времени со смартфоном благодаря функции Screen Time.
Реальность: стал постоянно смотреть в Screen Time, сколько времени и на что я потратил.
Ожидание: стал меньше проводить времени со смартфоном благодаря функции Screen Time.
Реальность: стал постоянно смотреть в Screen Time, сколько времени и на что я потратил.
В последнее время думаю о том, что очень жаль, что пока нет простого способа классифицировать и записать весь свой бытовой опыт: какое приложение лучше всего для ведения бюджета, какие подкасты слушать, какие места в городе самые интересные, какой рюкзак покупать не стоит, а какой — да.
На первый взгляд может показаться, что это очень индивидуальные вещи, но вполне может оказаться, что нет — рекомендательные алгоритмы Spotify тому пример.
Это такое кураторство 2.0 — вполне может быть, что в будущем благодаря алгоритмам прилетев в незнакомый город мы сможем пользоваться не стандартными путеводителями, а получать подборку советов, мест и лайфхаков от людей, которые слушают такую же музыку, как и мы, путешествуют так же, как и мы, предпочитают такую же еду и книги, придерживаются тех же политических взглядов.
Захотев приготовить что-то на ужин, мы получим идеальную подборку рецептов, а в интернет-магазине можно будет забыть о выборе из сотен моделей одежды, одевшись так же, как одеваются люди, похожие на тебя.
На первый взгляд может показаться, что это очень индивидуальные вещи, но вполне может оказаться, что нет — рекомендательные алгоритмы Spotify тому пример.
Это такое кураторство 2.0 — вполне может быть, что в будущем благодаря алгоритмам прилетев в незнакомый город мы сможем пользоваться не стандартными путеводителями, а получать подборку советов, мест и лайфхаков от людей, которые слушают такую же музыку, как и мы, путешествуют так же, как и мы, предпочитают такую же еду и книги, придерживаются тех же политических взглядов.
Захотев приготовить что-то на ужин, мы получим идеальную подборку рецептов, а в интернет-магазине можно будет забыть о выборе из сотен моделей одежды, одевшись так же, как одеваются люди, похожие на тебя.
Совсем забыл про сегодняшнюю презентацию Apple, и небо не упало на землю, макбук не взорвался, господи, чудеса!
Супер-фича новых macOS и iOS — считывание одноразовых паролей из SMS и Push-уведомлений и вставка их в запрашивающее приложение или сайт. Кажется, этот тот пример, где Apple из-за закрытой архитектуры годами отставала от Android, а сейчас сделала настолько нативно и круто, что Android'у просто никогда это не повторить с тем же уровнем удобства (потому что как ты SMS с телефона в Windows отправишь, то-то же).
В некоторых приложениях код вставляется без лишних кликов, просто приходит SMS, и код сразу в окошке, это вообще выглдяит как магия.
В некоторых приложениях код вставляется без лишних кликов, просто приходит SMS, и код сразу в окошке, это вообще выглдяит как магия.
Smartians — переходное звено между обычными вещами и умным домом.
Набор DIY компонент для превращения обычных приборов и вещей в умные: кнопки, крутилки, дёргалки и так далее. Неизвестно, как это будет вести себя в реальной жизни, но как концепт и база для дальнейших разработок очень круто.
http://frolicstudio.com/portfolio/smartians/
Набор DIY компонент для превращения обычных приборов и вещей в умные: кнопки, крутилки, дёргалки и так далее. Неизвестно, как это будет вести себя в реальной жизни, но как концепт и база для дальнейших разработок очень круто.
http://frolicstudio.com/portfolio/smartians/
Бюро Развития Гданьска раз в несколько лет организовывает аэрофотосъёмку города, по результатам которой можно посмотреть, как менялся город за последние 10 лет. Фотографии отличной детализации, карты ни капли не тормозят, сделано очень круто.
Сравнение по годам: http://gdansk.retromapy.pl
Фотографии с четырёх сторон (и ещё сверху): http://gdansk.ukosne.pl
Сравнение по годам: http://gdansk.retromapy.pl
Фотографии с четырёх сторон (и ещё сверху): http://gdansk.ukosne.pl
Когда ты публикуешь обновление приложения для звонков и не подумал над формулировкой.
Кажется, я старею и черствею. Возвращался домой на машине, опять долго искал в бардачке пульт от гаражных дверей — решил, что было бы здорово собрать на Arduino или Raspberry Pi штуку, которая бы при подъезде автоматически бы открывала ворота. Погуглил инструкции, разобрался в современных bluetooth-чипах, понял, что у меня пульт со сменным кодом, то есть просто так отправить сигнал по 433МГц не получится, подумал, что розетки рядом с кладовкой в гараже тоже нет, а от лампочки вести питание совсем колхоз, потом всё-таки решил разобраться с BT чипами для Ардуино, чтобы запитать от аккумулятора, но там всё хардкорно.
В общем, провёл так два часа, насытился и подумал, что просто прикреплю в укромном месте около руля пульт на двусторонний скотч.
В общем, провёл так два часа, насытился и подумал, что просто прикреплю в укромном месте около руля пульт на двусторонний скотч.
Написал небольшой post-mortem по перезапуску всех наших сайтов (vc.ru, TJournal и DTF) на новой версии платформы, которую мы разрабатываем.
https://tjournal.ru/team/81131-osnova-2-0
https://tjournal.ru/team/81131-osnova-2-0
Довольно интересная история, мне кажется — Danny van Kooten пишет, что два года назад они переписали сайт с Laravel на Go, потому что Go крутой (это правда), но сейчас переписали с Go обратно на PHP (Symfony 4), потому что поддерживать PHP, когда у тебя обычный сайт, намного проще, чем Go.
У меня у самого мысль переписать наши сайты на Go периодически проскакивает, но гоню её как могу — потому что с точки зрения бизнеса это ужасная затея. Поэтому тешим себя переписывая небольшие сервисы, в которых, конечно, купаемся в статической типизации и горутинах.
https://dannyvankooten.com/from-go-back-to-php-again/
У меня у самого мысль переписать наши сайты на Go периодически проскакивает, но гоню её как могу — потому что с точки зрения бизнеса это ужасная затея. Поэтому тешим себя переписывая небольшие сервисы, в которых, конечно, купаемся в статической типизации и горутинах.
https://dannyvankooten.com/from-go-back-to-php-again/
Awesome-подборка заблуждений разработчиков.
Например:
‣ В каждом дне 24 часа (нет, иногда мы переводим часы)
‣ Окей, в каждом дне в UTC ровно 24 часа (нет, бывают leap seconds)
‣ !def!xyz%abc@example.com — это невалидный email (ха-ха, валидный)
‣ У каждой страны есть столица (у Швейцарии нет)
‣ В каждом адресе есть название улицы (во многих небольших населённых пунктах в Европе нет названий у улиц)
‣ У человека есть имя (да и вообще, привет вашей БД, в которой есть поля first_name и last_name)
https://github.com/kdeldycke/awesome-falsehood
Например:
‣ В каждом дне 24 часа (нет, иногда мы переводим часы)
‣ Окей, в каждом дне в UTC ровно 24 часа (нет, бывают leap seconds)
‣ !def!xyz%abc@example.com — это невалидный email (ха-ха, валидный)
‣ У каждой страны есть столица (у Швейцарии нет)
‣ В каждом адресе есть название улицы (во многих небольших населённых пунктах в Европе нет названий у улиц)
‣ У человека есть имя (да и вообще, привет вашей БД, в которой есть поля first_name и last_name)
https://github.com/kdeldycke/awesome-falsehood
GitHub
GitHub - kdeldycke/awesome-falsehood: 😱 Falsehoods Programmers Believe in
😱 Falsehoods Programmers Believe in. Contribute to kdeldycke/awesome-falsehood development by creating an account on GitHub.
Мне очень нравится такой подход к дизайну — его не всегда удаётся воплотить в реальности, но очень важно периодически смотреть на свой продукт чужими глазами.
Прекрасно понимаю, что предложенная версия дизайна — утопия (или антиутопия), но не могу отделаться от ощущения, что страница, которую каждый из нас видит по несколько раз в день могла бы быть действительно лучше.
http://tonsky.me/blog/github-redesign/
P.S. Статистика там в конце не нужна, лучше расширить столбец со списком файлов.
Прекрасно понимаю, что предложенная версия дизайна — утопия (или антиутопия), но не могу отделаться от ощущения, что страница, которую каждый из нас видит по несколько раз в день могла бы быть действительно лучше.
http://tonsky.me/blog/github-redesign/
P.S. Статистика там в конце не нужна, лучше расширить столбец со списком файлов.
