Если они начнут свой карьерный путь с удалённой работы, это здорово их испортит как будущих профессионалов, потому что создается искажённое понимание сущности работы и взаимодействий. Да и брать неопытного новичка, да ещё удалённо — безумство храбрых. Это, пожалуй, самое опасное, что несёт удалёнка в HR-сфере. Всё же новый, молодой сотрудник должен формироваться при содействии ментора, наставника, внутри офисной жизни и общения с коллегами.
Как мне кажется, это утверждение из разряда «не служил — не мужик» и «не сидел — не мужик». Что подразумевается под «искажённым пониманием сущности работы»: неприятие корпоративного буллшита типа «мы тут семья», нелюбовь к общению на пустые темы, не относящиеся к работе, отсутствие трепетного отношения к руководству или что-то ещё?
Ментор с опытом удалённой работы и подобный же рекрутёр хорошо смогут и адаптировать новичка, и выявить его сильные и слабые стороны. Но да, тут появляется тот страшный для основной части «HR-специалистов» факт, что придётся действительно работать с ним, а не «отдавать в коллектив для формирования при содействии ментора, наставника, внутри офисной жизни и общения с коллегами».
Поднятие VPN прямо на роутере — что, кажется, умеют уже почти все более или менее нормальные роутеры прямо «из коробки», — имеет в данном случае один фатальный технический недостаток: оно не позволяет прорекламировать на Хабре услуги аренды VPS.
Ещё можно было реализацию упростить, сделав класс-наследник UIScrollView и внутри него реализовав реюз «ячеек» по типу той же UITableView (когда есть кэш ячеек, есть prepareToReuse и всё такое).
Тогда бы не было этих весёлых плясок с перемещением ячеек внутри scrollViewDidScroll:, т.к. можно было бы делать лэйаут всего видимого на экране прямо внутри layoutSubviews скролл-вью, как, насколько я понимаю, и подразумевалось писавшими UIKit людьми: определяешь видимый сейчас bounds, определяешь, ячейки с какими индексами должны быть видимы в этих bounds, создаешь / берёшь из кэша вьюхи для ещё не показанных ячеек, лэйаутишь их, а те, которые становятся невидимыми, убираешь с супервью и кладёшь в кэш. Снаружи остаётся только отдавать данные для наполнения этого скролл-вью и правильно реализовать targetContentOffset.
Такой вариант позволил бы не хардкодить количество ячеек на экране, а показывать столько, сколько влезает в ширину экрана (ваша реализация ведь совсем не подходит для iPad, где неплохо бы показать не один центральный и края двух соседних, а, допустим, три целиком и края двух). Ну и в ситуацию с «сломалось центрирование» вы бы так не попали.
Скорее всего это не «старые» номера, а «дополнительные». В договоре обслуживания у них была возможность указать ещё номер для контакта в случае, если по первому не могут связаться. Ну, что-то вроде «сначала звоним на основной, потом — на дополнительный, а потом пишем письмо по адресу, если уж совсем прижало».
Конечно, варианты реализации разные бывают, и кто-то действительно мог догадаться при смене номера старый не удалять, а скидывать в дополнительные (путём перевыставления флага «основной» на новом номере, ха-ха — фиг знает, какая у них там внутри структура хранения всего этого).
Раньше была возможность «удалить» дополнительные контактные номера методом корректировки договора.
Я, если память не изменяет, восемь лет назад знатно был удивлён наличием в договоре «дополнительного» контактного номера телефона, причём точно не моего и даже не мобильного. Причём в моей первичной копии это поле было пустым — заметил при открытии нового счёта. Сразу скорректировал, далее небольшое разбирательство с их СБ. В итоге кого-то там вроде даже уволили, но мне показалось, что в какой-то момент у них в системе просто поле было обязательным для заполнения, так что «писали как могли», чтобы данные были валидными с точки зрения системы.
Сейчас же, похоже, кто-то просто переписал SELECT, как ниже заметили.
Ну, наверняка это местные «бомбилы», которые возят из/в соседние большие города, BlaBlaCar и так далее. Т.е. просто может быть, что люди часто уезжают из таких городов в относительной спешке (отдых и работа), из-за чего всё-таки «душат жабу» и покупают билеты у местных официальных перевозчиков, а возвращаются уже «экономными» путями с пересадками в соседних городах и преодолением «последней мили» на неофициальных перевозчиках.
Скорее из-за местной специфики, а именно из-за нахождения на тупиковой ветке ЖД и отсутствию в городе международного аэропорта, что добавляет новые транзитные точки при необходимости попасть в другой город / другую страну.
Т.е. тут парадоксальная ситуация: и улететь, и уехать на поезде чаще всего и дешевле, и относительно удобнее из соседнего региона (Татарстан — Набережные Челны и Агрыз соответственно). Получается, что вместо прямого пути из точки А в точку Б люди тут чаще всего имеют одну-две пересадки в относительно больших хабах. Я не смотрел в исходные данные, но, скорее всего, это делает Ижевск сильно «путешествующим» городом.
Например, типичный вариант летнего отдыха — это что-то вроде «на машине до Агрыза, из Агрыза на поезде в Казань, из Казани самолётом в Анталию» или «на машине до Челнов, из Челнов самолётом в Москву, из Москвы — на пляж». Но, повторюсь, я не смотрел в модель, так что это лишь предположения.
Не могу ничего сказать по поводу такого вот подтверждения от Россмана, т.к. помню, из-за чего именно начался его истеричный крестовый поход против Эпл.
Беглый гуглинг не даёт ни подтверждения этого утверждения о невозможности закупа, ни опровержения, но статьи не 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 на эту программу говорит о том, что Эпл может как выделить кредитную линию для закупа запчастей, так и просто может предложить платить авансом.
Не думаю, что для участия в этой программе меняются процесс диагностики и закупа запчастей. Просто потому, что процесс диагностики и ремонта описан внутри Technician Guide.
Просто вы описали ситуацию, когда СЦ не хочет тратиться на запчасти сам и всё спихивает на клиента. Было бы желание, они бы держали запчасти на складе. У Эпла нет требования заменить деталь на ту, которую они выслали под конкретный ремонт — нужно просто поставить оригинальную и при необходимости обновить фирмварь.
Во-первых, вы неправду говорите: деталь в АСЦ приезжает до разбора устройства, если АСЦ её заказывает. Т.е. просто приходишь, говоришь тикет из саппорта / проблему и наличие гарантийной программы, тебе говорят, что позвонят, когда приедет деталь. Деталь приехала — звонят, забирают устройство, меняют в течение рабочего дня, отдают. Лично проверено на заменах экранов трёх макбуков.
Во-вторых, вы правы: АСЦ должен выслать дефектную запчасть для получения новой. Но нужно это потому, что во всех Apple Technician Guide есть процедуры проверки устройств на дефекты, которые подразумевают, что у АСЦ должен быть пул заведомо исправных запчастей для диагностики и ремонта. И, если ваш АСЦ хороший и не пожалел денег на этот пул, вам, скорее всего, заменят деталь на новую из пула, а вашу дефектную обменяют на новую, тем самым пополнив пул.
Если же новой детали в пуле нет — придётся ждать.
Если же и пула нет — скажите «привет» диагностике уровня «мы думаем, что надо заказать новую материнскую плату в ваш iMac — возможно, поможет; не поможет — будем смотреть дальше».
У вас обработкой диплинка занимается вью-контроллер, а не, допустим, AppDelegate?
Я не могу понять, почему бы на основе диплинка (это же будет UIApplicationLaunchOptionsRemoteNotificationKey внутри launchInfo либо тот же remoteNotificaton в нужном методе) сразу не составить навигационный стек, чтобы не презентовать последовательно несколько вью-контроллеров.
Во избежание костылей множества if-else блоков для обработки каждой ситуации, cплэш скрин будет показываться на уровне UIWindow.
Это же можно решить не вкорячиванием ещё одного-двух UIWindow, а реализацией на уровне композиции навигационного стека. Положить в rootViewController сплэш, потом с кастомным транзишном показать нужный вам вью-контроллер (главную / профиль / что угодно). Если не нравится внутри навигационного стека, можно модальную презентацию сделать, в конце концов.
Т.е. вместо использования способа, доступного с iOS 7, который заключается в реализации только кастомного транзишна, вы сделали два (!) дополнительных UIWindow и добавили дополнительной и сомнительно нужной логики. Довольно спорное решение.
При том, что если вы стремитесь выстрелить себе в ногу, пуша два контроллера одновременно и анимировано, это полностью ваша проблема, а не «ошибка» UINavigationController. Если нужно запушить в стек два и более контроллера, правильнее сделать так:
Хотя я не могу представить сценария, где надо пушить контроллеры одновременно: пуш должен быть инициирован пользователем, и сразу после пуша пользователь должен иметь возможность вернуться назад, совершив ровно одно действие. Если же действие пользователя инициирует двойной, тройной и т.д. пуш, пользователь слегка удивится тому, что кнопка «назад» возвращает его не на тот контроллер, из которого он сюда попал.
Вы серьёзно считаете, что из-за button.exclusiveTouch = NO стоит писать целую статью? Это всё тянулось как минимум с iOS 6, где можно было развлекаться, роняя системные приложения подобным образом. Другой вопрос, почему Apple решили, что UButton должен по умолчанию иметь .exclusiveTouch = NO, и почему не исправляли это так долго.
Ну и вы лукавите, что «В сети описание этой ошибки встречается очень редко, а решение было найдено всего одно, и оно не работает»: раз, два (аж 2012 год).
Множество подобных «багов» появляются как результат восстановления системы из бэкапа Time Machine при обновлении устройства. Сам пару дней назад столкнулся с подобным: настроил новую прошку сначала как новое устройство, затем накатил бэкап и получил те самые «проблемы с Wi-Fi в Yosemite», о которых сейчас так любят говорить.
Помогла переустановка системы и восстановление из бэкапа без восстановления настроек компьютера и сети. Скорее всего это является следствием конфликтов старых kext (которые какого-то чёрта уходят в бэкап вместе с файлами пользователя) и нового железа, но это лишь предположение.
Обычно у Apple происходит выпуск новых продуктов по такой схеме:
1. Apple покупает какую-то компанию и ее наработки включаются в продукты Apple (Покупка AuthenTec запуск Touch ID)
2. Руководство Apple встречается с руководством другой компании, происходит анонс нового продукта от Apple (Возможно, анонс Apple Car Play как то связан с встречей Кука и Маска)
Что-что? =) Все последние продукты, — именно продукты, а не технологии! — такие как iMac, MacBook, iPod, iPhone и iPad, в Apple разработали и запустили самостоятельно.
data breachunintended offsite backup, так что им не стоит волноваться о сохранности их данных.Как мне кажется, это утверждение из разряда «не служил — не мужик» и «не сидел — не мужик». Что подразумевается под «искажённым пониманием сущности работы»: неприятие корпоративного буллшита типа «мы тут семья», нелюбовь к общению на пустые темы, не относящиеся к работе, отсутствие трепетного отношения к руководству или что-то ещё?
Ментор с опытом удалённой работы и подобный же рекрутёр хорошо смогут и адаптировать новичка, и выявить его сильные и слабые стороны. Но да, тут появляется тот страшный для основной части «HR-специалистов» факт, что придётся действительно работать с ним, а не «отдавать в коллектив для формирования при содействии ментора, наставника, внутри офисной жизни и общения с коллегами».
Source: 8 лет удалённой работы.
Тогда бы не было этих весёлых плясок с перемещением ячеек внутри scrollViewDidScroll:, т.к. можно было бы делать лэйаут всего видимого на экране прямо внутри layoutSubviews скролл-вью, как, насколько я понимаю, и подразумевалось писавшими UIKit людьми: определяешь видимый сейчас bounds, определяешь, ячейки с какими индексами должны быть видимы в этих bounds, создаешь / берёшь из кэша вьюхи для ещё не показанных ячеек, лэйаутишь их, а те, которые становятся невидимыми, убираешь с супервью и кладёшь в кэш. Снаружи остаётся только отдавать данные для наполнения этого скролл-вью и правильно реализовать targetContentOffset.
Такой вариант позволил бы не хардкодить количество ячеек на экране, а показывать столько, сколько влезает в ширину экрана (ваша реализация ведь совсем не подходит для iPad, где неплохо бы показать не один центральный и края двух соседних, а, допустим, три целиком и края двух). Ну и в ситуацию с «сломалось центрирование» вы бы так не попали.
Конечно, варианты реализации разные бывают, и кто-то действительно мог догадаться при смене номера старый не удалять, а скидывать в дополнительные (путём перевыставления флага «основной» на новом номере, ха-ха — фиг знает, какая у них там внутри структура хранения всего этого).
Я, если память не изменяет, восемь лет назад знатно был удивлён наличием в договоре «дополнительного» контактного номера телефона, причём точно не моего и даже не мобильного. Причём в моей первичной копии это поле было пустым — заметил при открытии нового счёта. Сразу скорректировал, далее небольшое разбирательство с их СБ. В итоге кого-то там вроде даже уволили, но мне показалось, что в какой-то момент у них в системе просто поле было обязательным для заполнения, так что «писали как могли», чтобы данные были валидными с точки зрения системы.
Сейчас же, похоже, кто-то просто переписал SELECT, как ниже заметили.
Т.е. тут парадоксальная ситуация: и улететь, и уехать на поезде чаще всего и дешевле, и относительно удобнее из соседнего региона (Татарстан — Набережные Челны и Агрыз соответственно). Получается, что вместо прямого пути из точки А в точку Б люди тут чаще всего имеют одну-две пересадки в относительно больших хабах. Я не смотрел в исходные данные, но, скорее всего, это делает Ижевск сильно «путешествующим» городом.
Например, типичный вариант летнего отдыха — это что-то вроде «на машине до Агрыза, из Агрыза на поезде в Казань, из Казани самолётом в Анталию» или «на машине до Челнов, из Челнов самолётом в Москву, из Москвы — на пляж». Но, повторюсь, я не смотрел в модель, так что это лишь предположения.
Беглый гуглинг не даёт ни подтверждения этого утверждения о невозможности закупа, ни опровержения, но статьи не 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 есть процедуры проверки устройств на дефекты, которые подразумевают, что у АСЦ должен быть пул заведомо исправных запчастей для диагностики и ремонта. И, если ваш АСЦ хороший и не пожалел денег на этот пул, вам, скорее всего, заменят деталь на новую из пула, а вашу дефектную обменяют на новую, тем самым пополнив пул.
Если же новой детали в пуле нет — придётся ждать.
Если же и пула нет — скажите «привет» диагностике уровня «мы думаем, что надо заказать новую материнскую плату в ваш iMac — возможно, поможет; не поможет — будем смотреть дальше».
Т.е. всё упирается в жадность АСЦ.
Я не могу понять, почему бы на основе диплинка (это же будет UIApplicationLaunchOptionsRemoteNotificationKey внутри launchInfo либо тот же remoteNotificaton в нужном методе) сразу не составить навигационный стек, чтобы не презентовать последовательно несколько вью-контроллеров.
Это же можно решить не вкорячиванием ещё одного-двух UIWindow, а реализацией на уровне композиции навигационного стека. Положить в rootViewController сплэш, потом с кастомным транзишном показать нужный вам вью-контроллер (главную / профиль / что угодно). Если не нравится внутри навигационного стека, можно модальную презентацию сделать, в конце концов.
Т.е. вместо использования способа, доступного с iOS 7, который заключается в реализации только кастомного транзишна, вы сделали два (!) дополнительных UIWindow и добавили дополнительной и сомнительно нужной логики. Довольно спорное решение.
Хотя я не могу представить сценария, где надо пушить контроллеры одновременно: пуш должен быть инициирован пользователем, и сразу после пуша пользователь должен иметь возможность вернуться назад, совершив ровно одно действие. Если же действие пользователя инициирует двойной, тройной и т.д. пуш, пользователь слегка удивится тому, что кнопка «назад» возвращает его не на тот контроллер, из которого он сюда попал.
Ну и вы лукавите, что «В сети описание этой ошибки встречается очень редко, а решение было найдено всего одно, и оно не работает»: раз, два (аж 2012 год).
Помогла переустановка системы и восстановление из бэкапа без восстановления настроек компьютера и сети. Скорее всего это является следствием конфликтов старых kext (которые какого-то чёрта уходят в бэкап вместе с файлами пользователя) и нового железа, но это лишь предположение.
Что-что? =) Все последние продукты, — именно продукты, а не технологии! — такие как iMac, MacBook, iPod, iPhone и iPad, в Apple разработали и запустили самостоятельно.