В сети раскритиковали затратность технической архитектуры Parler

У них ведь перед выселением с AWS случился data breach unintended offsite backup, так что им не стоит волноваться о сохранности их данных.

С глаз долой, из сердца вон. Опасна ли удалёнка для компании?

Если они начнут свой карьерный путь с удалённой работы, это здорово их испортит как будущих профессионалов, потому что создается искажённое понимание сущности работы и взаимодействий. Да и брать неопытного новичка, да ещё удалённо — безумство храбрых. Это, пожалуй, самое опасное, что несёт удалёнка в HR-сфере. Всё же новый, молодой сотрудник должен формироваться при содействии ментора, наставника, внутри офисной жизни и общения с коллегами.

Как мне кажется, это утверждение из разряда «не служил — не мужик» и «не сидел — не мужик». Что подразумевается под «искажённым пониманием сущности работы»: неприятие корпоративного буллшита типа «мы тут семья», нелюбовь к общению на пустые темы, не относящиеся к работе, отсутствие трепетного отношения к руководству или что-то ещё?

Ментор с опытом удалённой работы и подобный же рекрутёр хорошо смогут и адаптировать новичка, и выявить его сильные и слабые стороны. Но да, тут появляется тот страшный для основной части «HR-специалистов» факт, что придётся действительно работать с ним, а не «отдавать в коллектив для формирования при содействии ментора, наставника, внутри офисной жизни и общения с коллегами».

Source: 8 лет удалённой работы.

VPN в домашнюю локалку

Поднятие VPN прямо на роутере — что, кажется, умеют уже почти все более или менее нормальные роутеры прямо «из коробки», — имеет в данном случае один фатальный технический недостаток: оно не позволяет прорекламировать на Хабре услуги аренды VPS.

Бесконечный скролл с баннерами, или Как обойтись тремя вьюхами

Ещё можно было реализацию упростить, сделав класс-наследник UIScrollView и внутри него реализовав реюз «ячеек» по типу той же UITableView (когда есть кэш ячеек, есть prepareToReuse и всё такое).

Тогда бы не было этих весёлых плясок с перемещением ячеек внутри scrollViewDidScroll:, т.к. можно было бы делать лэйаут всего видимого на экране прямо внутри layoutSubviews скролл-вью, как, насколько я понимаю, и подразумевалось писавшими UIKit людьми: определяешь видимый сейчас bounds, определяешь, ячейки с какими индексами должны быть видимы в этих bounds, создаешь / берёшь из кэша вьюхи для ещё не показанных ячеек, лэйаутишь их, а те, которые становятся невидимыми, убираешь с супервью и кладёшь в кэш. Снаружи остаётся только отдавать данные для наполнения этого скролл-вью и правильно реализовать targetContentOffset.

Такой вариант позволил бы не хардкодить количество ячеек на экране, а показывать столько, сколько влезает в ширину экрана (ваша реализация ведь совсем не подходит для iPad, где неплохо бы показать не один центральный и края двух соседних, а, допустим, три целиком и края двух). Ну и в ситуацию с «сломалось центрирование» вы бы так не попали.

Сбербанк начал отображать в мобильном приложении ранее использовавшиеся номера клиентов как их дополнительные номера

Скорее всего это не «старые» номера, а «дополнительные». В договоре обслуживания у них была возможность указать ещё номер для контакта в случае, если по первому не могут связаться. Ну, что-то вроде «сначала звоним на основной, потом — на дополнительный, а потом пишем письмо по адресу, если уж совсем прижало».

Конечно, варианты реализации разные бывают, и кто-то действительно мог догадаться при смене номера старый не удалять, а скидывать в дополнительные (путём перевыставления флага «основной» на новом номере, ха-ха — фиг знает, какая у них там внутри структура хранения всего этого).

Сбербанк начал отображать в мобильном приложении ранее использовавшиеся номера клиентов как их дополнительные номера

Раньше была возможность «удалить» дополнительные контактные номера методом корректировки договора.

Я, если память не изменяет, восемь лет назад знатно был удивлён наличием в договоре «дополнительного» контактного номера телефона, причём точно не моего и даже не мобильного. Причём в моей первичной копии это поле было пустым — заметил при открытии нового счёта. Сразу скорректировал, далее небольшое разбирательство с их СБ. В итоге кого-то там вроде даже уволили, но мне показалось, что в какой-то момент у них в системе просто поле было обязательным для заполнения, так что «писали как могли», чтобы данные были валидными с точки зрения системы.

Сейчас же, похоже, кто-то просто переписал SELECT, как ниже заметили.

Сценарии заражения в конкретных городах на основе датасета передвижения людей по России

Ну, наверняка это местные «бомбилы», которые возят из/в соседние большие города, BlaBlaCar и так далее. Т.е. просто может быть, что люди часто уезжают из таких городов в относительной спешке (отдых и работа), из-за чего всё-таки «душат жабу» и покупают билеты у местных официальных перевозчиков, а возвращаются уже «экономными» путями с пересадками в соседних городах и преодолением «последней мили» на неофициальных перевозчиках.

Сценарии заражения в конкретных городах на основе датасета передвижения людей по России

Скорее из-за местной специфики, а именно из-за нахождения на тупиковой ветке ЖД и отсутствию в городе международного аэропорта, что добавляет новые транзитные точки при необходимости попасть в другой город / другую страну.

Т.е. тут парадоксальная ситуация: и улететь, и уехать на поезде чаще всего и дешевле, и относительно удобнее из соседнего региона (Татарстан — Набережные Челны и Агрыз соответственно). Получается, что вместо прямого пути из точки А в точку Б люди тут чаще всего имеют одну-две пересадки в относительно больших хабах. Я не смотрел в исходные данные, но, скорее всего, это делает Ижевск сильно «путешествующим» городом.

Например, типичный вариант летнего отдыха — это что-то вроде «на машине до Агрыза, из Агрыза на поезде в Казань, из Казани самолётом в Анталию» или «на машине до Челнов, из Челнов самолётом в Москву, из Москвы — на пляж». Но, повторюсь, я не смотрел в модель, так что это лишь предположения.

Apple планирует ввести неожиданные проверки ремонтных мастерских, штрафуя за использование запрещенных комплектующих

Не могу ничего сказать по поводу такого вот подтверждения от Россмана, т.к. помню, из-за чего именно начался его истеричный крестовый поход против Эпл.

Беглый гуглинг не даёт ни подтверждения этого утверждения о невозможности закупа, ни опровержения, но статьи не The Verge и 9to5mac говорят о том, что некоторые, кто всё-таки подписывает контракт, «said that they simply valued the opportunity to get parts directly from the manufacturer».

UPD

Ну, или он опять говорит очень обтекаемо. Я нашёл только вот это в документах:

«Note, Apple provides a credit line to successful eligible applicants for use with Apple purchases (e.g. required tools, equipment, service parts). Locations that cannot meet credit requirement may submit an Irrevocable Standby Letter of Credit from your bank, a cash deposit, or pay for parts in advance.»

Т.е. даже Application Form на эту программу говорит о том, что Эпл может как выделить кредитную линию для закупа запчастей, так и просто может предложить платить авансом.

Apple планирует ввести неожиданные проверки ремонтных мастерских, штрафуя за использование запрещенных комплектующих

Не думаю, что для участия в этой программе меняются процесс диагностики и закупа запчастей. Просто потому, что процесс диагностики и ремонта описан внутри Technician Guide.

Просто вы описали ситуацию, когда СЦ не хочет тратиться на запчасти сам и всё спихивает на клиента. Было бы желание, они бы держали запчасти на складе. У Эпла нет требования заменить деталь на ту, которую они выслали под конкретный ремонт — нужно просто поставить оригинальную и при необходимости обновить фирмварь.

Apple планирует ввести неожиданные проверки ремонтных мастерских, штрафуя за использование запрещенных комплектующих

Во-первых, вы неправду говорите: деталь в АСЦ приезжает до разбора устройства, если АСЦ её заказывает. Т.е. просто приходишь, говоришь тикет из саппорта / проблему и наличие гарантийной программы, тебе говорят, что позвонят, когда приедет деталь. Деталь приехала — звонят, забирают устройство, меняют в течение рабочего дня, отдают. Лично проверено на заменах экранов трёх макбуков.

Во-вторых, вы правы: АСЦ должен выслать дефектную запчасть для получения новой. Но нужно это потому, что во всех Apple Technician Guide есть процедуры проверки устройств на дефекты, которые подразумевают, что у АСЦ должен быть пул заведомо исправных запчастей для диагностики и ремонта. И, если ваш АСЦ хороший и не пожалел денег на этот пул, вам, скорее всего, заменят деталь на новую из пула, а вашу дефектную обменяют на новую, тем самым пополнив пул.

Если же новой детали в пуле нет — придётся ждать.

Если же и пула нет — скажите «привет» диагностике уровня «мы думаем, что надо заказать новую материнскую плату в ваш iMac — возможно, поможет; не поможет — будем смотреть дальше».

Т.е. всё упирается в жадность АСЦ.

Делаем вездесущий Splash Screen на iOS

У вас обработкой диплинка занимается вью-контроллер, а не, допустим, AppDelegate?

Я не могу понять, почему бы на основе диплинка (это же будет UIApplicationLaunchOptionsRemoteNotificationKey внутри launchInfo либо тот же remoteNotificaton в нужном методе) сразу не составить навигационный стек, чтобы не презентовать последовательно несколько вью-контроллеров.

Делаем вездесущий Splash Screen на iOS

Во избежание костылей множества if-else блоков для обработки каждой ситуации, cплэш скрин будет показываться на уровне UIWindow.

Это же можно решить не вкорячиванием ещё одного-двух UIWindow, а реализацией на уровне композиции навигационного стека. Положить в rootViewController сплэш, потом с кастомным транзишном показать нужный вам вью-контроллер (главную / профиль / что угодно). Если не нравится внутри навигационного стека, можно модальную презентацию сделать, в конце концов.

Т.е. вместо использования способа, доступного с iOS 7, который заключается в реализации только кастомного транзишна, вы сделали два (!) дополнительных UIWindow и добавили дополнительной и сомнительно нужной логики. Довольно спорное решение.

Как скрэшить любое приложение на айфоне, и как этого не допустить

Ну не все используют эту технологию. :)

Как скрэшить любое приложение на айфоне, и как этого не допустить

При том, что если вы стремитесь выстрелить себе в ногу, пуша два контроллера одновременно и анимировано, это полностью ваша проблема, а не «ошибка» UINavigationController. Если нужно запушить в стек два и более контроллера, правильнее сделать так:

UIViewController* firstViewController = [[UIViewController alloc] init];
UIViewController* secondViewController = [[UIViewController alloc] init];
UIViewController* thirdViewController = [[UIViewController alloc] init];

[self.navigationController pushViewController:firstViewController animated:NO];
[self.navigationController pushViewController:secondViewController animated:NO];
[self.navigationController pushViewController:thirdViewController animated:YES];

[firstViewController release];
[secondViewController release];
[thirdViewController release];

Хотя я не могу представить сценария, где надо пушить контроллеры одновременно: пуш должен быть инициирован пользователем, и сразу после пуша пользователь должен иметь возможность вернуться назад, совершив ровно одно действие. Если же действие пользователя инициирует двойной, тройной и т.д. пуш, пользователь слегка удивится тому, что кнопка «назад» возвращает его не на тот контроллер, из которого он сюда попал.

Как скрэшить любое приложение на айфоне, и как этого не допустить

Вы серьёзно считаете, что из-за button.exclusiveTouch = NO стоит писать целую статью? Это всё тянулось как минимум с iOS 6, где можно было развлекаться, роняя системные приложения подобным образом. Другой вопрос, почему Apple решили, что UButton должен по умолчанию иметь .exclusiveTouch = NO, и почему не исправляли это так долго.

Ну и вы лукавите, что «В сети описание этой ошибки встречается очень редко, а решение было найдено всего одно, и оно не работает»: раз, два (аж 2012 год).

5 принципов тестирования мобильных приложений

К сожалению, с Android я не работаю, поэтому не могу подсказать. Но Гугл говорит, что можно так и так.

5 принципов тестирования мобильных приложений

Можно так, например:

Борьба с проблемой в лэптопе, или почему крупные компании позволяют себе такие баги?

Множество подобных «багов» появляются как результат восстановления системы из бэкапа Time Machine при обновлении устройства. Сам пару дней назад столкнулся с подобным: настроил новую прошку сначала как новое устройство, затем накатил бэкап и получил те самые «проблемы с Wi-Fi в Yosemite», о которых сейчас так любят говорить.

Помогла переустановка системы и восстановление из бэкапа без восстановления настроек компьютера и сети. Скорее всего это является следствием конфликтов старых kext (которые какого-то чёрта уходят в бэкап вместе с файлами пользователя) и нового железа, но это лишь предположение.

Умный дом от Apple грядёт: вероятно, анонс уже в понедельник

Обычно у Apple происходит выпуск новых продуктов по такой схеме:
1. Apple покупает какую-то компанию и ее наработки включаются в продукты Apple (Покупка AuthenTec запуск Touch ID)
2. Руководство Apple встречается с руководством другой компании, происходит анонс нового продукта от Apple (Возможно, анонс Apple Car Play как то связан с встречей Кука и Маска)

Что-что? =) Все последние продукты, — именно продукты, а не технологии! — такие как iMac, MacBook, iPod, iPhone и iPad, в Apple разработали и запустили самостоятельно.