• Директор по маркетингу Apple Фил Шиллер заявил, что дети с хромбуками не добьются успеха
    +1
    Прав Шиллер или нет — никому знать не дано, потому что станет ли успешным ребенок — зависит не только от техники, которой он пользуется (ваш кэп). Но вот фраза действительно резкая и прозвучала вполне однозначно. В любом случае, Шиллеру наверняка намылят голову, так как скандалы любой компании нужны меньше всего, у них и так проблем хватает. Это либо неосторожность со стороны Шиллера, либо спланированный акт привлечения внимания.
  • «Извини, но у меня депрессия»: как работать с заболевшим сотрудником
    0
    Да независимо от оплаты, даже если это х2 от рынка, лень и желание обмануть остается, и оно очень хорошо работает.
  • «Извини, но у меня депрессия»: как работать с заболевшим сотрудником
    +7
    Грустно прозвучит, но учитывая менталитет наших людей — стремление обмануть всех, кого возможно — это работать не будет. Работодатель, идущий навстречу сотрудникам, рискует быстро столкнуться с «депрессиями», которых на самом деле нет, и которые берутся методом «знакомый врач» или «хочу доп. отпуск, так что скажусь больным». Другая сторона — человек действительно может быть болен, и будет неправильно ему не помочь (а то и загнать в депресс еще глубже, выказав ему недоверие), но распознать реальную болезнь среди толп желающих воспользоваться лазейкой или просто мнительных людей — я бы сказал, невозможно. Ситуация безвыходная. Независимо от стороны, которую займешь, с другой тебя постараются нахлобучить тем или иным способом. Таковы уж люди, особенно, к сожалению, наши.

    P.S. По тесту — 17 баллов, moderate depression. Что очень похоже на истину. Если б не проходил спец. медикаментозную поддержку — была бы very severe, так что все в норме.
  • Изменения модальной презентации экранов в iOS 13
    +2
    Спасибо, конечно, но, честно говоря, местами перевод напоминает гугл транслейт. Хотя бы вот в этом участке:
    Однако, я чувствую, что должен предотвратить это на экране «Добавить / изменить профиль таймера», так как существует риск потери изменений. Будет ли пользователь ожидать, что изменения будут отменены или сохранены, если экран был закрыт?

    Это не звучит по-русски. Не говоря о том, что последнее предложение в этом абзаце и вовсе трудно понять правильно, пока несколько раз не прочитаешь контекст. Можно было бы перевести более вольно, но и более «живым» и понятным языком, например, так:
    Однако можно заметить, что закрытие смахиванием не совсем подходит к экрану «Добавить/изменить настройки таймера», потому что пользователю может быть непонятно, как именно смахивание повлияет на результат — отменит внесенные им изменения или же сохранит их.

    Ну правда, раз уж это перевод, то надо бы перевести с адаптацией к языку и русской речи, а не просто по словам. Но все равно спасибо.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    0
    Если уже имеется альтернативное и более правильное решение — опять-таки, опытный разработчик должен его найти и применить взамен более популярного, об этом я и говорил ранее.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    +2
    Все так, опыт человека как раз и состоит в том, чтобы не кидаться на первое найденное решение в незнакомой ему области, а найти несколько подходов, разобраться в них, сравнить между собой и выбрать лучший.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    +1
    Да у всего в нашем мире есть обратная сторона. Просто когда ищут человека, «знающего все подряд» — находят посредственность, потому что универсальных специалистов по всем вопросам не существует. А если ищут человека с вроде бы конкретными навыками, но при этом не знают, как и куда его навыки применить — это просто пустая трата времени и средств, а также провокация недовольства самого сотрудника, если он видит, что занимается ерундой, а не тем, чем хотел бы.

    Применительно к Яндексу и другим крупным похожим компаниям — у них сильная текучка кадров, и развит принцип нанимать сразу много стажеров, чтобы потом так же много отсеивать при сокращениях штата. Суммарно, даже с занижением зарплаты, выходит все равно наверняка дороже, чем нанять изначально более дорогих, но и более подходящих к работе специалистов, и поставить их на сопровождение конкретных продуктов. Но, возможно, тот факт, что Яндекс занимается еще и аутсорсингом, поддерживая множественные проекты от других компаний, и не дает им возможности нанимать конкретных специалистов — гораздо проще набрать толпу теоретиков и бросать их между проектами, пока не останутся единицы, подходящие для их специфики. И так по кругу. А такое положение дел внутри компании ни разу не играет на уверенность сотрудников в завтрашнем дне, что еще сильнее провоцирует разобщенность коллектива и нестабильность команд.

    А по поводу библиотек — как ни крути, но все более-менее крупные проекты вынуждены на чем-то базироваться. При всем желании невозможно забить на библиотеку, которую вы упоминаете (или любое другое существующее решение), и написать полностью что-то свое. Точнее, возможно, но настолько дорого по деньгам и времени, что никто этим заниматься не станет. И вряд ли уже существующее тяжеловесное решение может быть идеально переписано — оно будет решать ряд имеющихся проблем, но и привнесет массу новых, так как идеала нет и быть не может.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    +32
    Вот в этом весь Яндекс, как и многие похожие крупные компании. Многоступенчатые интервью с теоретическими тяжелыми (и крайне специфическими) вопросами, которые на практике либо никак и нигде не применяются, либо влет заменяются давно реализованными решениями из сети. То есть, спрашивают просто ради того, чтобы спросить. Мне тоже предлагали собеседоваться у них — я каждый раз отказывал, так как если компания при собеседовании опирается не на людей с практическим опытом решения конкретного спектра задач, а просто на то, знает ли человек, что такое красно-черное дерево, — ничего хорошего в этой компании можно не ждать, потому что они сами не в курсе, какой именно специалист им требуется. С моей точки зрения, такие вопросы выглядят примерно так: «Я хочу, чтобы вот эта машина умела быстро ездить, хорошо поворачивать, варить кофе, делать массаж, рассказывать анекдоты и общаться со мной на японском… Правда, я планирую ее использовать для фотосессии в своем гараже, но это не так уж важно, главное — чтобы все умела, и подешевле!».

    Давно уже прошли времена, когда нужно было удерживать в голове тонну бесполезной информации, которая «может быть, разок за жизнь пригодится». Сейчас куда важнее уметь искать и правильно использовать то, что нашел. Мне не нужно знать, какова формула Эйлера, — я просто мгновенно найду ее в сети, когда она понадобится. И мне не требуется даже знать, что такая формула существует — достаточно понимать, где и как искать информацию по конкретной задаче, а уж способы ее решения (или хотя бы их составные части) давно уже существуют в сети.

    Самый ценный сотрудник — это опытный неконфликтный специалист, который при столкновении с неизвестной ему задачей быстро разберется, какие в ней могут быть узкие места, шустро найдет и изучит нужную информацию и грамотно применит ее для решения. Такому человеку не нужно помнить, какая сложность у конкретного алгоритма сортировки — он просто моментально найдет варианты и выберет правильный, основываясь на собственном опыте и найденной информации. А теоретик, влет пишущий код по конкретной задачке на листочке, зачастую окажется полностью небоеспособным в незнакомых ему ситуациях и будет значительно дольше топтаться на одном месте, зато да, сложность алгоритмов расскажет хоть посередине ночи…

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

    За статью большое спасибо. И удачи в дальнейшей карьере!
  • Сбербанк заявил, что нашел виновного в утечке данных клиентов
    +7
    Ну, он сам выбрал свою дорогу, не вижу ничего, о чем стоило бы сожалеть.
  • Вклад дизайнера в разработку мобильных приложений
    +1
    Вашу бы статью да всем дизайнерам дать почитать… Профессионалам — просто согласиться, новичкам и тем, кто считает себя профессиональными дизайнерами (но ими не являются) — узнать много нового. На своей памяти встречал только одного крутого дизайнера, который делал все, как полагается, и тем самым сильно ускорял процесс разработки. Жаль, что таких мало.
  • Почему Senior Developer'ы не могут устроиться на работу
    0
    Удивили. Впервые за все прочитанные комменты увидел правильный подход к собеседованиям. Правильное собеседование — это дать практически полезную задачу (не алгоритмическую, а что-то из реальных вещей), запихнуть человека в привычную для него рабочую среду и посмотреть, как он ее сделает, со всеми сопутствующими телодвижениями. Это и даст мало-мальски полную картину отношения к работе. Приятно видеть, что есть люди, кто это понимает.
  • Из веба и банков в iOS-разработку: личный опыт программиста Apiqa
    0
    Про отличие структуры и класса — это очень важный и закономерный вопрос, а вот по поводу алгоритмических моментов — их всем задают, независимо от уровня собеседуемого, без понятия, зачем. Чаще всего этим грешат крупные компании, которые, видимо, не представляют, что еще можно спросить. Наличие опыта, разумеется, важно, но если его нет в направлении iOS — это заинтересует только те компании, у которых ну совсем все плохо с наймом кадров.
  • Из веба и банков в iOS-разработку: личный опыт программиста Apiqa
    +2
    Никак, к сожалению. Во-первых, объективно, самостоятельная тренировка никогда не даст вам опыта продуктовой разработки (реальные приложения в реальных условиях + командная работа над мобильными проектами, там своя специфика). И во-вторых, никто не даст вам уровень миддла, если вы не имеете опыта работы в этой сфере (в том числе по вышеупомянутой причине). Если вы хотите продолжать получать хорошую зп, но желаете сменить профиль на iOS — я бы рекомендовал вам сделать так, как сделал в свое время я — совмещать две работы. Работать по фронту, на фулл-тайм или парт-тайм, зарабатывать тем, что вы умеете хорошо. И попутно наняться на позицию Junior iOS-разработчика, работая за те деньги, что предлагают, и набираясь опыта. Через 2-3 года при должной квалификации вы уже сможете стать миддлом.

    И, кстати, по поводу «в родном городе нет вакансий» — по мобильной разработке много удаленных предложений. Поищите, пусть даже на небольшие деньги. Это избавит вас от ненужных трат по переезду.
  • Из веба и банков в iOS-разработку: личный опыт программиста Apiqa
    +4
    Немного странный способ написать резюме. И странный ресурс, чтобы его размещать. 4 года разработки вообще — это почти ничто, учитывая, что за это время вы сменили уже несколько платформ. Поймите правильно, учиться — это замечательно, но весь ваш пост выглядит, как рекламно-поучительный текст. При том, что, объективно, вы еще ничего не знаете о платформе, на которую перешли. Независимо от усидчивости, старательности и таланта, за год-два вы не набьете и 10% шишек, которые присущи профессионалам в этой области (как и в любой другой, впрочем), и которые как раз определяют опыт в конкретной сфере.

    Руки тянутся разобрать всю статью по цитатам, но это долго и наверняка бесполезно.

    P.S.
    мы стали заниматься продуктовой разработкой в сфере ЖКХ.

    Я очень надеюсь, что у вас есть опытные разработчики. Просто слишком уж много появляется «приложений», созданных за невменяемые деньги, которые
    то глючит, то зависает, то ломается
  • Росреестр разъяснил, как защититься от сделок по ЭЦП
    +2
    Блин, до чего бестолковая система, а! Мошенничество явное есть, давно выявлено, но сервис не перекрыли до окончания разбирательства, точных инструкций, как и что заполнять, нигде нет, сам сайт Росреестра требует крипто-плагин ЭЦП для работы. Количество дыр радует! Теперь все можно сделать без моего участия, даже если я не оформлял ЭЦП. Великолепно!
  • Мошенники и ЭЦП — всё очень плохо
    0
    А, т.е. «заблаговременно» защититься не выйдет? Супер… Но хотя бы так. Спасибо за ответ! «Автоматический мониторинг», я так понимаю, это услуга какая-то платная у аутсорсных бухгалтерских компаний? Или в ЛК налоговой включается?
  • Мошенники и ЭЦП — всё очень плохо
    0
    Есть так называемая «38-я форма», а если быть точнее форма 38001, заполнив которую, можно запретить регистрацию юр. лиц, без личного присутствия

    Перерыл половину интернета, форма 38001 — это «возражение» против совершаемых действий. Как его заполнять, если, тьфу х3, меня эта проблема с мошенниками еще не коснулась? Как запретить вообще любые действия без моего присутствия? Где об этом посмотреть, как заполнять заявление? Весь интернет пестрит фразами «заполните — и будете защищены» (но как заполнять — никто не объясняет), а юридические сайты отсылают к законам, где лишь набор слов, понятный разве что юристам. Как заполнить человеку (ИП/физик), который просто не хочет, чтобы без его присутствия что-то делали?
  • Поднимаем читаемость кода в iOS разработке
    0
    Во-первых, в таком случае они должны быть вместе с публичными свойствами, а они от них унесены неизвестно куда.

    Не должны. Лучше иметь отдельный участок-секцию кода, где идут только свойства, упорядоченные по порядку паблик-readonly-приват. А потом уже идет конструктор, и лишь потом — публичные методы. Смешивать код по принципу модификатора доступа — не самая удачная идея, потому что их мало (часто используемых — всего два). Так ваш код разобьется всего на две огромных секции внутри файла. А разделение по смысловым элементам (typealias'ы, свойства, приватные свойства, конструктор/деструктор, методы, приватные методы, реализация протоколов) дает куда больше секций в коде, а значит, и повышает простоту восприятия его структуры. Аналогия: что проще, книга на тему «Программирование» из двух огромных общих глав, или из двадцати, но более конкретных?

    а почему, собственно, то, как класс выглядит «снаружи», должно влиять на то, как он расположен в файле?

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

    И да, есть вариант «отсматривать автоматически создаваемое подобие хедера файла» через спец. кнопку в Xcode, но это довольно тормозная штука, и поэтому, лично на мой взгляд, неудобная.
  • Поднимаем читаемость кода в iOS разработке
    0
    Почему так, а не «публичный метод и используемые им приватные методы»?

    Отвечу со своей колокольни. В варианте «сначала паблик, потом приват» при отсмотре файла вы точно знаете, что если видите приватный метод, то все, публичные — закончились. А если делать вперемешку, как вы предложили, то вы никогда не узнаете, где и когда в файле заканчиваются публичные методы. А учитывая, что свифтовый код пишется в одном файле (без хедеров, отделяющих публичную часть), то при изучении чужого кода на предмет «что там где находится, что умеет класс, какие свойства и методы отдает наружу и т.д.» вам будет на порядок сложнее разобрать каждый незнакомый вам класс. Ваш подход удобен лишь «для себя самого», пока на проекте все известно, и нет людей, не знакомых с кодом. А еще нет авралов.
  • Поднимаем читаемость кода в iOS разработке
    +1
    Поддерживаю. Сам стараюсь в проектах, где работаю, добровольно-принудительно вводить такой же порядок. Очень помогает преобразить код из состояния «свалка» в состояние «книга».
  • Bluetooth LE не так уж и страшен, или Как улучшить пользовательский опыт без особых усилий
    0
    Большое спасибо за подробную статью, мне как раз в скором времени эта информация очень пригодится.
  • AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
    0
    В двух словах: «Альтернативная IDE». Написана иначе, на другом языке, обладает тонной интересных плюшек (не всем они нужны, но есть — и хорошо), по производительности и багам — где-то лучше Xcode, где-то AppCode. Я пока так и не смог перейти на AppCode, в основном, из-за тормозов с автокомплитом и «java-style» внешности и отклика управления. Не знаю, как объяснить последний свой пункт, но вот как-то прям чувствуется, это приложение работает иначе, чем привык в Xcode, скролл не такой плавный, выравнивание элементов другое (по отступам слева), и т.д. Вкусовщина.
  • «Черный ящик» для автомобилей обойдется правительству в 100 млн рублей
    0
    Подтверждаю, у нового VW Polo (купили месяц назад) эта шняга в подстаканнике есть. Чуть не выдрали по первости, думали, стаканчик какой, потом дилера спросили, сказали «не выдирайте, она там намертво, и это динамик глонасса».
  • The New iOS Mobile Enterprise. Часть #1: Кодогенерация для ресурсов
    0
    Да, либа отличная, пользуюсь уже во втором проекте и доволен, как слон. Она реально экономит тонну времени и нервов.
  • Безопасность в iOS приложениях
    0
    Про пункт 1 не соглашусь, как и Funbit. Все действия по шифрованию передаваемых данных будут «лишними» только при условии 100% гарантии, что канал передачи данных не взломан. А если MITM? А если подмена сертификатов? В случае отсутствия дополнительных ступеней защиты, после взлома канала передачи данных все данные будут скомпрометированы. А вот если данные зашифрованы, то вскрытие канала взломщику не то чтобы прям сильно поможет. Безопасности много не бывает, чем больше замков на двери — тем меньше шанс, что ее вскроют за разумное время и деньги.
  • Codable для API запросов и как навести в коде порядок
    0
    Очень неплохо, спасибо, стало значительно круче.
  • Codable для API запросов и как навести в коде порядок
    0
    Можно. А все, что сделал автор в либе, можно сделать и без этой либы. Но я говорю конкретно о ней и ее фишках, а не о других способах выполнить задачу. Другие способы есть всегда.
  • Codable для API запросов и как навести в коде порядок
    0
    Перечитал статью, подумал вот о чем. Мне сильно не хватает в оберточных либах возможности делать dependent-запросы. То есть, зачастую нужно, чтобы отработал вот этот запрос, потом вот этот, и еще вот этот, и только тогда считать группу запросов выполненной. Например, если каждый из них отработал без ошибок, или только парочка из трех запрошенных, допустим. Сейчас решаю это тупой вложенностью (один запрос — onSuccess — второй запрос — onSuccess, и т.д.), что не совсем верно, так как запросы не одновременно идут, но мне хватает. Есть ли планы ввести что-то подобное в либу?

    Еще похожая тема — chained-запросы, при котором один запрос идет строго после другого, цепочкой, а результатом является опять результат выполнения группы цепных запросов.

    И еще одно — отмена запросов. Юзер перешел на другой экран, ткнул отмену или что-то такое — надо иметь возможность обрубить левые запросы, которые более не нужны.

    С этими плюшками будет прям огонь.
  • Codable для API запросов и как навести в коде порядок
    +1
    Неплохой подход. Наверное, каждый что-то подобное пилит в каждом своем проекте)) У меня тоже что-то такое встроено самописное поверх Аламофаера. Но возьму на заметку, спасибо. Если будете поддерживать либу, то отлично.

    P.S. Где-то в разметке статьи забыли <i* тег закрыть, или закрыли не там, где стоило) Пофиксите пж, а то весь подвал в курсиве)
  • Авторизация без авторизации: не собираем персональные данные
    0
    Wine? Если приложение простое, по идее, оно подцепится. Ну, либо виртуалки.
  • Application Coordinator в iOS приложениях
    0
    Код менять всегда придется, само собой ничего не произойдет. Однако одно дело — править код в единственном месте (в координаторе, максимум — в нем и плюс еще в рутовом, который может удерживать на него ссылку), а совсем другое — во всех местах, связанных с данным контроллером (когда у вас 5 экранов реализуют один и тот же код вызова контроллера — править придется 5 мест).

    Это всегда две стороны одной медали. Чем больше разделение ответственности — тем сложнее структура системы, но тем проще ее модификация, сопровождение и тестирование (при условии, что человек разобрался в архитектуре, конечно же, и реализует ее корректно). И наоборот, чем меньше разделение — тем проще ориентироваться в структуре проекта, тем меньше требуемая квалификация (пока багов нет и контроллеры не разрослись выше 1000 строк), однако тем тяжелее и трудозатратнее становится расширять систему. Совместить «лучшее из лучших» не получится, во всяком случае, на данный момент ничего не придумано. Предложенный подход с координаторами — нечто среднее по сложности между MVC/MVP и VIPER, некий компромисс, кроме того, ее сложность можно подстроить под проект, это уже зависит от навыка архитектора. Лично мне подход нравится.

    На мой взгляд, «серебряной пули» в виде идеальной архитектуры нет и быть не может, под каждую задачу есть свое подходящее решение. Реализовывать тяжеловесный VIPER в двухэкранном приложении — дико избыточная и нерентабельная затея, но и писать огромное банковское приложение на базе традиционного MVC — тоже так себе идея. Если утрировать, шуруп можно и молотком забить, но лучше все же воспользоваться отверткой.
  • Application Coordinator в iOS приложениях
    +1
    Предложите ваш вариант реализации в отдельной статье на хабре. Возможно, ваш подход действительно окажется удобнее, так почему бы не показать ваши навыки и не поделиться знаниями через собственную полезную статью?
  • А в ваших iOS приложениях IBOutlet уже private?
    0
    Ой как много воды о том, что такое инкапсуляция (что аутлеты не должны торчать наружу)… И, кстати говоря, это зависит от применяемой архитектуры, иногда нужно как раз наоборот. Но если «по-простому» — то да, в большинстве случаев аутлеты, если уж вы их используете, делаем приватными, чтобы извне был доступен минимум информации. Все, вся статья в двух предложениях.
  • Тест Android vs iOS: два полюса силы
    +1
    Убрали косяк в первом вопросе, смотрю? А они еще остались, и это я еще андроид не смотрел, ибо не моя стихия. Но неважно. Потестил я тут слегка ваш тест, обнаружил, что можно легко накрутить результат, если просто проходить тест раз за разом, даже браузеры не обязательно переключать. Наверное, при простейшей реализации добиться уникальности результатов слишком сложно, спорить не буду, но сам факт — «заруба» нерелевантная, не только из-за качества тестов, а еще и из-за отсутствия ограничителя на неограниченное перепрохождение.
  • Тест Android vs iOS: два полюса силы
    +3
    Поддерживаю. Underground state отобразился как неверный вариант — ну крайне любопытно, где ж там такой. За 7 лет работы в iOS не заметил ничего похожего. Да и другие вопросы к тесту есть. Слабо составлено, если это пропустили организаторы как релевантный опрос — то там реально делать совершенно нечего, раз даже на уровне ревью и организации мероприятия так относятся к подаче информации.
  • Контроль над ресурсами. Настраиваем SwiftGen
    +2
    Спасибо за статью. Как вариант — посмотрите библиотеку R.swift на гитхабе. Если верно понял, она решит большую часть ваших задач, и еще с более изящным кодом на выходе, а также с минимальными настройками и элементарной интеграцией (однострочный скрипт в настройках проекта и копипаста сгенерированного файла один раз в сам проект). Я сейчас ее пользую, и очень доволен, плюсы все те же, что вы перечислили (плюс легкая настройка + поддержка, кроме локализации и изображений, еще и шрифтов, XIB'ов и цветов). Из минусов — тоже не умеет отсекать неиспользуемые ресурсы.
  • Квест, который никто не может пройти
    0
    Короче, на втором задании после часа попыток мне надоело тратить время впустую. Кто догадался — я реально завидую вашим телепатическим навыкам, мне до такого еще далеко. Пойду лучше продолжу работать, это полезнее. P.S. После окончания конкурса напишите, что имели в виду на шаге два. Мне интересно, как далеко зашла телепатическая фантазия.
  • Квест, который никто не может пройти
    +2
    В итоге, прошел задачу методом брутфорса. Но это явный косяк в формулировках, конечно. Над этим плохо поработали.
  • Квест, который никто не может пройти
    +8
    Честно говоря, постановка задач удручает. Найти ссылку — элементарно, но вот формулировка первого же задания — сомнительна. После прочтения вопроса я сходу подумал о bash, футболе, хоккее, асме и еще много о чем. Слишком размытое задание. Чтобы не посчитали спойлером: «Какая… тут указана». Так вот, "..." у меня ассоциируется просто с тучей областей, а не с чем-то конкретным. Это называется нечеткое ТЗ. Куда лезть и что искать, чтобы получить подсказку, — это понятно, но вот сам вопрос — это «принеси то, не знаю что». Квест, на мой взгляд, должен быть сложным, но при этом с четкой постановкой задач, а не угадайка и телепатия. Но это имхо, разумеется. А так, буду честен, из-за формулировки пощелкал варианты на первой задаче и пока (а может, и вообще) отложил это дело.
  • Kivy — фреймворк для кроссплатформенной разработки №1
    0
    Я не разбираюсь в Андроиде, поэтому не могу взять на себя право сказать, что какой-то фреймворк самый крутой для иос и андроида одновременно. Вы же делаете такое заявление, но при этом показываете, что в иос не разбираетесь, значит, ваше заявление так же голословно, как если бы его произнес я. Но вообще — нет, конечно, не будем «пинать воздух». Я вам уже писал огромный пост, на который вы не нашли, что возразить, и просто его проигнорировали. Ваша сущность уже давно понятна, с первых ваших ответов в комментах (не мне), так что особо тут обсуждать нечего. Каждый… ит как хочет, поэтому успеха.