Как стать автором
Обновить
4
0

Пользователь

Отправить сообщение
Самая большая проблема Slack для меня, как корпоративного пользователя — отсутствие полной истории сообщений. Такой банальной функции как списка всех моих бесед в хронологическом порядке в Slack нет — там только 11 последних чатов/каналов. Я общаюсь с десятками людей, о которых я помню только то что я с ними что-то обсуждал, очень сложно найти человека по такому критерию.
Я задумался, «неужели это работает и для тех кто использует слепую печать?», внезапно — да! Из статьи: «Huntand-peck typers were more susceptible with highest mean word recovery of 83% (top-200, 4K dictionary), followed by hybrid typers at 74% and touch-typers at 71%.».

Раз так, интересно, можно ли эту технологию скомбинировать с технологией анализа радио эфира, чтобы угадывать что набирают люди за непрозрачной стеной =)
Если я правильно понимаю исходник, то они сначала на DLP 3D принтере печатают иглы без обратно смотрящих шипов, затем как-то химически обрабатывают, чтобы шипы появились. Печатают с варьированием материалов и параметров.

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

Аналогично печатают в 2D, затем собирают 3D объекты, например, стенки коробки.
Не соглашусь насчёт текстов на дорожных знаках. Ездил кататься по Калифорнии, дорожные знаки гораздо понятнее и дружелюбнее чем в России. Стаж вождения 3+ года, до сих пор иногда задумываюсь насчёт значения некоторых дорожных знаков в России (т.е. не всегда очевидно что некоторые знаки означают, долю секунды думаю, затем понимаю). Возможно, это связано с относительной сложностью правил в России, но дорожные знаки в США мне было удобнее и проще воспринимать (при этом с ПДД Калифорнии я ознакомился за пару дней до поездки).
Теперь в их пользовательской базе будет как большая часть работоспособного взрослого населения (Linkedin) так и пол детей мира (Minecraft). Они хотят всех, интересно, что из этого получится.
Аналогичная ситуация, но признаки я встречал, поэтому сейчас немного удивлен их отсутствием.

Насчет опасности: я не про навешивание свойств в категории, это не будет работать, только если они выплюнут «бинарно совместимый» класс и засвиззлят -class и кучу всего ещё. Такое бывает, но редко и нам об этом никто не рассказывает. Такое действительно очень маловероятно.

Насчет наследования сейчас просто начнется холивар, так что, думаю, не стоит его начинать, всем понятна противоположная точка зрения.
Да, всё верно, сейчас везде возвращается UIButton(по крайней мере -class возвращает его, не проверял все типы) и документация (обычно) явно описывает вопросы сабклассинга. Но, я помню времена, когда от типа зависел возвращаемый сабкласс. И достаточно много времени потратил на исследования различных хаков, которые применяет эппл под капотом. Сейчас не могу нагуглить, но я читал множество предостережений насчет UIButton и его отношения к class cluster, ребята из WWDC Labs советуют этого не делать.

То что это работает сейчас не значит, что это продолжит работать завтра. Сабклассить UIButton и навешивать это всё через IB — скользкая опасная дорога. Сегодня UIButton можно достаточно гибко кастумизировать, и я бы предпочел использовать средства UIButton, или сабкласс UIControl.
Заглянул в доки — действительно, формально он не класс кластер (по крайней мере так не пишут прямо), так что тут я не прав. Но сабклассить его всё равно не стоит хотябы потому, что никто не гарантирует каким образом будет реализована иерархия классов и как API может измениться со временем.
И как это работает, например, с UIButton? Плохая идея сабклассить класс кластеры. Но вообще, если использовать нибы, IBDesignable действительно удобный инструмент.
Можно поподробнее о «нарушении формата»? Поковырял интеграцию Xcode с XLIFF ещё раз и немного сам стандарт. Не понял про «таблички из оригинальной строки и перевода к ней». Ключи на языке разработки — это как раз та практика, которую предлагает Apple (я её не поддерживаю). Xcode работает с файлами ресурсов (т.е. ключи даже не обязательно использовать из кода) и он использует и ключ и перевод.

Например, для такой строчки:

/* Testy Commenty! */
"testy" = "ru Testy!";


Получается такой кусок в одном из XLIFF:

<trans-unit id="testy">
        <source>en Testy!</source>
        <target>ru Testy!</target>
</trans-unit>


Просто API работает так, что, если для ключа нет перевода, то NSLocalizedString + NSString возвращают ключ.
Или может быть я что-то упустил?
Самый главный минус XLIFF — это отсутствие нормальной поддержки плурализации («один конь», «два коня»). Этого вполне достаточно, чтобы окончательно закопать эту технологию для нормального использования. Вся суть в (ещё более) удобном отделении данных о локализации и супер удобное взаимодействие с локализаторами. XLIFF распространенный формат, для него есть куча софта и он используется на разных платформах. Получается, что вашим локализаторам прийдется часть ресурсов размещать в XLIFF, а часть в проприетарном замороченном apple формате .stringsdict. Естественно они делать этого не будут (или будут плохо) и все прелести автоматизации сходят на нет.

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

Так что я бы рекомендовал какое-то другое решение для управления локализациями.
Интересно, как юридически дела обстоят между Apple и Paramaunt Pictures, в iOS можно установить клингонский язык в список предпочитаемых и (если разработчики локализуют свое приложение на клингонский) пользоваться приложением на любимом языке.
Да тут целый букет антипаттернов. Супер, давайте значит, будем пропагандировать shared mutable state, да ещё и запихнем его в синглтон. Но нет, мы на этом не остановимся, давайте ещё прикольнее сделаем, давайте обернем это всё ещё и в #define.

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

image
Я правильно понял, они сравнивали разных людей? У них же получилось что-то вроде средней температуры по больнице.

Я в свое время научился слепому 10 (на самом деле 9ти, без правого большего) пальцевому набору, до этого набирал полузрячим методом. И разница значительная, на пике полузрячего было на реальных текстах ~300-350 символов в минуту, сейчас ~450-515, при этом, на синтетических текстах бывают скорости и выше 700 знаков в минуту. У меня нет к этому таланта, это просто ежедневная практика (не тренировки, я просто каждый день пользуюсь клавиатурой) и немного силы воли на старте. Это очень полезный навык и я настоятельно рекомендую его всем разработчикам, писать код слепым методом гораздо удобнее.
Но бывают и другие люди, у которых есть к этому талант, они могут быть самоучками, могут быть задротами трудягами, часами оттачивая скорость в каких-нибудь клавогонках. Так что вариативность людского восприятия и ловкости играют тут большую роль.

Слепой 10-пальцевый набор сокращает количество движений, что физически более эффективно, если упростить, можно представить две огромные кнопки справа и слева и экран, на котором появляется надпись «правая» или «левая»:
  • 2-пальцевый зрячий набор: вы смотрите на экран, читаете что нужно нажимать, смотрите на кнопки, читаете, что на них написано, протягиваете правую руку и нажимаете
  • 10-пальцевый слепой набор: вы держите левую руку над левой кнопкой, правую над правой, смотрите на экран и тут же нажимаете нужной рукой нужную кнопку.


Вот так же и с 10-пальцевым слепым набором, одним пальцем нажимается обычно 3 разных кнопки (без цифр). Для личного увеличения производительности за приемлемое время лучше на самом деле пройти эти курсы, это можно сделать бесплатно и не сетовать на то что какие-то там другие люди могут научится печатать так же быстро одним сломанным пальцем с завязанными руками пока отбиваются от дракона находясь под водой.
Тут помогает разумное использование трекера задач и чего-то вроде git-flow, когда на каждую таску есть ветка. Лень никто никогда не отменят, даже у самых занудных разработчиков, себя я спас от приступов лени, написав pre-commit скрипт, который из названия текущей ветки выдирает айди задачи в таск трекере и прилепляет перед сообщением.

На самом деле многое зависит от команды и проекта, но, в целом, в статье рекламируется отличная практика.
Яростно поддерживаю! Батарея деградировала всего за 3-4 месяца. 3 месяца, карл! Теперь он держит не 6-7 дней, а несколько часов, например два. Никогда ещё не сталкивался с подобной халатностью разработчиков, как можно выпускать продукты с таким процентом брака просто непонятно. Jawbone теперь в черном списке. Надеюсь, это поможет кому-нибудь.

P.S. А теперь представьте, что это был подарок на новый год, который сломался через 3 месяца.
А знаете, я бы сравнил Apple Watch (для пользователей продукции Apple) с горячей водой. Можно и без неё обойтись, но с ней гораздо лучше. Я использую их именно так как и планировал до покупки — как сопутствующее устройство для лопаты iPhone 6+. Не ожидал, но очень часто пользуюсь звонками с часов — очень удобно и не нужно искать телефон, кроме того, «Директор? Да пошел ты в жжж директор» сразу с часов. Иногда даже забываю телефон дома (sic!), до часов со мной никогда такого не происходило. Постоянно смотрю погоду и использую календарь — без быстрого доступа к этой информации уже неудобно. Естественно часы, уведомления и таймер — регулярно. Сири работает на удивление хорошо, но, увы, хорошо только в хороших условиях, за рулем, когда она на самом деле нужна бывают проблемы.

К сожалению, приходится констатировать, что часы ещё сырые, софт кривой, digital crown — неудобное угло (могли бы и нормально сделать), быстро разряжаются и официально водостойкие а не водонепроницаемые, т.е. в них нельзя мыться/плавать чтобы вам там эксперименты и опыт людей не говорил. Ещё одна неприятная особенность — спортивный ремешок, одевать его, если у вас на руках волосы неприятно и даже может быть больно, но быстро привыкаешь и не замечаешь. Пульсометр мерит пульс не постоянно и чтобы начать ему нужно лет 500. Но все эти недостатки для меня не особо заметны (решение моих задач недостатки Apple Watch не слишком сильно затрагивают).

Ещё это единственные умные часы, которые полноценно будут работать с вашими сообщениями и звонками на айфоне, для меня это критично.
Я с детства мечтал о таких часах, поэтому купил несмотря на сырость и дороговизну. Рекомендую подождать следующей версии.
Ребят, на мой взгляд вы знатно испоганили свой продукт. Уточню, я насчет iOS версии, не пользовался остальными. Стало жутко неудобно, непонятно и криво. Я не буду детально расписывать все проблемы UX и UI, если вы их не видите, то у вас очень большие проблемы. Я как пользователь вижу факап, как разработчик вижу ещё больший факап.

Не хотелось бы чтобы такой замечательный сервис пропал, я благодарен вам за него, пользовался почти ежедневно в течение нескольких лет. Желаю вам удачи и скорейшего разрешения этой проблемы, но, серьезно, wtf? Кто вообще до такого смог додуматься?
Давно рассматриваю 15 дюймовую версию как наиболее вероятный вероятный вариант личного ноутбука. Сейчас рабочий pro 13 — маловат, но увеличение цены почти в два раза как-то совсем отбивают желание что-то покупать. Забавно, раньше я считал что 140к это слишком дорого.

Кстати, почему 15 дюймовый лично для тебя менее удобен чем 13? Тяжеловат и громоздок? Не помещается никуда?

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Зарегистрирован
Активность