Простите, пользователи macOS, но Apple зашла слишком далеко

Пока цена портирования и поддержка платформы выше, чем выручка с нее — можно и не начинать. Для игры имеет смысл рассматривать iOS и iPadOS как платформу для жизни, где много денег и пользователей. Может быть даже больше, чем в windows. И для indie игры в первую очередь стремиться туда. С выходом Catalina портировать игру на macOS большого труда не составит. И будет сразу одним релизом будет закрыто три платформы.

Финансовая ловушка в Яндекс.Деньги

Разумно было бы до идентификации разрешить оплачивать услуги со своей банковской карты, а кошелек пополнять не давать. И услуга оплачена и денег лишних на счету не зависнет.
Я сам попал в ту же ситуацию лет 5 назад. Хотел кому-то денег перевести на ЯД, к себе на кошелек кинул, а перевести уже не смог. Хотя пополнить чужой кошелек со своей карточки можно без проблем. А казалось бы это равноценные операции.
5 лет прошло, а воз и ныне там.

Чем проще задача, тем чаще я ошибаюсь

Rubber duck debugging. Пока рассказывал в чем проблема, сам понял из-за чего так происходит.

Как я делал трекер парковки для людей

Я бы считал сколько времени человек идет от последнего нормального локейшена/построеного маршрута и закладывал столько же времени на обратную дорогу.

Офлайн навигация не так сложна, как может показаться. Но пользователю надо будет предварительно качать навигационные данные для своего города.

Как я делал трекер парковки для людей

Все хорошо. Но как быть если интернет пропал? Сразу говорить пользователю чтобы шел к машине? Или вы зашли в здание и GPS уплыл в соседний район. У вас ломается предсказание, сколько идти обратно и не ясно в какую сторону. Может начать думать, что машина рядом, а может наоборот.

(Не очень) скрытые издержки общей кодовой базы iOS и Android

Расскажу свою историю: Мы делаем фреймворки для офлайн карт, навигации, поиска на iOS и Android. Код максимально шарится между платфомами. Приведу пример: Для того чтобы показать вьюху с картой на стороне ОС мы обрабатываем касания, реализуем API для взаимодействия с компонентом и создаем surface для рендера. Весь остальной код пишется на C++. И там его очень много. Парсинг данных, парсинг стиля, применение стиля к данным, подготовка данных для OpenGL/Metal, весь сетевой стек, очереди фоновых задач, обработка данных пользователя. API, которое видит разработчик — это просто верхушка айсберга. Это с одной стороны. Много сложного кода, его лучше писать один раз. И ошибки ловить один раз.
При этом мы делаем приложения Guru Maps на своих же фреймворках. И тут ситуация обратная весь интерфейс и большинство кода этих приложений пишутся так, как это принято на конкретной архитектуре. Общий код на C++ тоже есть, но его мало. Это работа с данными и конверсия между бинарным форматом,GPX,KML в любую сторону.
Категоричный вывод о том что общий код на C++ вреден — я бы не делал. Он сильно облегчает жизнь. Но это должно быть что-то такое, в чем нужна скорость и нет зависимости от специфичных для платформы плюшек.

Ну Apple, BLEee

И не только номера. Любопытно будет посмотреть на проверку атаки. Кто возьмет валидное пространство номеров телефонов для страны и попробует найти там номер по 3 байтам 32 байтного хэша. Интересно сколько там будет коллизий.

Ну Apple, BLEee

Нет. Не при попытке отправить, а когда хотим принять и не номер даем, а настройку приватности AirDrop открываем на 5 минут.

Ну Apple, BLEee

Так у большинства стоит настройка. «Принимать файлы только от знакомых». Все остальные запросы с мусором даже появляться не будут. Без превью, без соблазнительных картинок и т.д.

Зачем нужны дженерики в Go?

А в чем собственно проблема? Вы же сейчас прочитали абстрактный кусок кода, сделали какие-то выводы и спрашиваете у меня верны ли эти выводы.

Да я считаю, что конверсию типов надо проверять. Да, все ошибки, которые возвращает api надо проверять. Да, если что-то может пойти не так, надо проверить, все ли хорошо. И если произошло что-то нештатное, действовать по обстоятельствам: отправлять ошибку выше по стеку, обрабатывать, пробовать снова или что-то еще.

Но это все риторика о том как обрабатывать ошибки.

Усложнение концепции языка не защитит от ошибок, а наоборот сделает код сложнее и ошибок станет больше. Несмотря на благие намерения. Стандартные библиотеки go показали, как на нем можно решать прикладные задачи и без дженериков.

Зачем нужны дженерики в Go?

Может быть я не работал на сложных проектах на Go. Но работал на сложных проектах на C++. Где стрелять себе в ногу проще по многим причинам. И если есть возможность не писать хреновый код, его не надо писать. Могу понять студенческие поделки, но в продакшене такого быть не должно. Язык сам дает инструменты, чтобы проверять, что все норм. Почему бы ими не воспользоваться?

Тут у вас есть возможность проверить, успешный ли каст или нет. Добавили проверку — все работает.

В каком случае может возникнуть необходимость делать касты без проверки я не могу представить.

Зачем нужны дженерики в Go?

На основании функций, которые тип реализует, а интерфейс требует?

package main

import "fmt"
import "math"

type geometry interface {
	area() float64
	perim() float64
}
type circle struct {
	radius float64
}
func (c circle) area() float64 {
	return math.Pi * c.radius * c.radius
}
// func (c circle) perim() float64 {
// 	return 2 * math.Pi * c.radius
// }
func measure(g geometry) {
	fmt.Println(g)
	fmt.Println(g.area())
	fmt.Println(g.perim())
}
func main() {
	c := circle{radius: 5}
	measure(c)
}

Компилятор возвращает ошибку:

test.go:29:9: cannot use c (type circle) as type geometry in argument to measure:
circle does not implement geometry (missing perim method)

Научите, как сделать панику в рантайме.

Зачем нужны дженерики в Go?

Погодите, а откуда паника появится? Если на этапе компилации уже будет все проверено, чтобы входные типы умели делать то, что требует интерфейс.

Зачем нужны дженерики в Go?

Для меня golang прекрасен именно отсутствием генериков и гибкими интерфейсами. Эти два подхода замечательно заменяют друг друга. Ты хочешь обязать какой-то объект обладать какими-то свойствами. Опиши это в интерфейсе и передавай в функцию свой интерфейс. Все. Не надо шаблон. Функция будет работать одинаково для всех типов, которые подходят под интерфейс. Я пишу часто на C++ и в моей жизни хватает шаблонов. Пожалуй их даже слишком много и Golang как глоток свежего воздуха с подохдом интерфейсов.

Если реализовывать два подохда одновременно. Будет каша и путаница.

Челобитная в Apple

Пишут они все понятно. И рассказывают и показывают на примерах и когда дают реджект там тоже в тексте указывают что не так. Да бывает тяжело найти, среди всего текста тот заветный абзац. Если сейчас перечитаете изначальный реджект, неужели там не было ничего о описании и иконке?

DeviceLock DLP: Цены российского черного рынка на пробив персональных данных (плюс ответ на ответ Тинькофф Банка)

У некоторых весь трафик пишется. А вы говорите что доступ к приватной информации не логируют. Это можно объяснить только безалаберностью. Для мобильных приложений логируется каждый чих, чтобы смотреть тенденции в поведении пользователей. Так и своих работников надо мониторить и смотреть каждый чих и запрос. И если будут подозрения в сливе инфы, это будет явно видно.

Математическое расследование, как подделывали выборы губернатора в Приморье 16 сентября 2018 года

Криптовалюты подсказывают направление. Когда уперлись в скорость CPU, на помощь приходит GPU. Когда и его мало — ASIC.

Билайн показывает рекламу боту Google. Бот недоволен

Ну можно не в суд идти, а на хабр и показывать конкретику. Какой скрипт куда встраивается и что делает. И для каких User-Agent это срабатывает. Любопытные проверяют все у себя и возможно, подают в суд коллективный иск. Шумиха и репутационные потери будут и без суда.
Я так понимаю, что вмешиваться в трафик своих клиентов они начали уже давно и не прекращали с тех пор. Теперь аппетиты несколько выросли и они начали уже в транзитном трафике копаться.

Билайн показывает рекламу боту Google. Бот недоволен

Надо брать за жабры. Ставить запись всего трафика в дамп на сервере и на клиенте. И суду показывать рядом одну версию и вторую.

Google: разрыв отношений с Huawei опасен для национальной безопасности США

Кто-то испугался, что достаточно большие средства будут вложены в создание форка и он будет хорошим.