Pull to refresh
3
0
Оленёв Кирилл@agent10

Senior Software Engineer at mail.ru

Send message
2. Их и раньше особо не было да и сейчас нет. Большинство разработчиков — самоучки.
3. 4. То что вы описываете похоже на некий железный занавес/советский союз для разработчиков. Неужели мы такая угроза?:) И опять же из ваших мыслей не понятно — кому это выгодно? Частным компаниям или государству? Частным компаниям в целом должно быть всё равно, главное их собственный доход. Для государства все эти действия могут спровоцировать сильнейшую утечку кадров…
Выглядит немного фантастично:
2. Что мешает использовать мигрантов уже сейчас? И каких/откуда?
3. Кому запретят? Частным компания? Удалёнщикам? Далее, как запретят? Интернет запретят, общение, пересылку исходников, Git? Или вывод денег со счетов?
4. А кому будет нужна отечественная платформа? Это будет типа сколково? Законодательно будет запрещено использовать Java/C++?
А как будет реализовываться этот заговор? Будут резко понижать, плавно или не повышать в течение десятков лет?
Но тогда, как вы сами сказали ниже, все просто начнут работать удалённо на другие страны. Как следствие дефицит кадров и зарплаты придётся поднимать.

А с инструкторами лётных училищ сравнивать не очень верно, без инструкторов — всего лишь меньше лётчиков в стране.
А без разработчиков — меньше выпускаемых продуктов/услуг — меньше доход верхушек компаний…
Только вы забыли указать, что Instant Run на данный момент не поддерживается при следующих изменениях:
  • Add/remove/change annotations
  • Add/remove/change an instance field
  • Add/remove/change a static field
  • Add/remove a static method signature
  • Change a static method signature
  • Add/remove an instance method
  • Change an instance method signature
  • Changing which parent class the current class inherits from
  • Change the list of implemented interfaces
  • Changing static initializer of a class
Я понял, что ради уменьшения)
Я не понимаю, для чего готовить и мержить ресурсы, которые в результате будут выкинуты.

Например, у меня 10 языков, в каждом по 2 тысяче строк.
Но у меня не для всех flavors нужны все языки, где-то надо всего 2 языка.
Если бы ресурсы игнорировались на начальном этапе это могло бы немного, но повысить скорость сборки.
Напрашивается вопрос — а зачем?) Я, конечно, детально со всеми этапами не знаком, но на лицо куча лишних действий)
А указание resConfigs влияет только на последний шаг сборки, грубо говоря, только на размер apk? Т.е. разнообразный мёржинг ресурсов остаётся и на скорость сборки это не влияет?
Попробовал ради интереса перенести, прирост всё же есть, но не очень значительный: на моей машине быстрее стало строиться примерно на 9%. До переноса среднее время было 112 секунд, после стало 102 секунды.
Статья об архитектурных подходах кастомизации/брендирования нативно написанных приложений с кучей кода и кучей заказчиков… Как технологии, которые вы перечислили связаны с этим?
Да, прямо так и лежит. Но подключается зависимостями через gradle. Но у нас, 90% работы именно с общим кодом. А как думаете ускорится ли сборка при переносе в main?
Скажите, а не усложняется ли навигация по проекту, когда весь общий код в main?
В нашем проекте ~7 приложений, исторически весь общий код как раз вынесен в отдельный library project, тогда как основной flavor main «пустует».
Пока переносить я не решаюсь, сейчас визуально работать проще(как мне кажется)…
Очень здорово.
А не было желания создать свой целый курс «Пишем свою ОС с нуля за 16 32 64 дня» попутно рассказывая принципы работы микропроцессоров и ОС в деталях? Основная суть была бы в том, чтобы создавать конкретную работающую вещь, под конкретный тип/типы процессоров и видеть работу на реальных железках.
А всё таки есть ли разница в выборе якорной вьюшки, если нет необходимости менять списку ориентацию? Если да, то когда какую лучше брать?
клиенты мессенджера Slack

Попробовал в Slack просто сообщением — не получается…
С удовольствием почитал бы о рендеринге текста. Читал уже, что используете SDF и т.д. но хотелось бы детальнее.
Посмотрел исходники. Получается, что параметры плагинов зашиты в сами плагины, например версия sdk, build tools и т.д. Скажем есть два вообще разных приложения с разными minSdkVersion, то как применить ваши плагины к этим приложения?
Ну смотрите как получается.
Скажем для «раздельной» разработки нужно 1 Андроид разраб и 1 iOS.
1) В вашем случае получается, что всё равно нужен 1 Андроид разраб + нужен разработчик со знанием сразу и Java(Android) и iOS SDK. Т.е. всё равно 2 человека надо.
2) Будет ли меньше багов и упростится ли поддержка кода? Во-первых, вы сами пишете про платформенно-независимый код, что
эта величина может достигать 60%
Т.е. я предполагаю, что помимо двух отдельных UI будет ещё и зависимый код под платформу + общую часть также нужно будет архитектурно создавать сразу независимой от платформы(что в целом хорошо, но может быть сложнее).

Вероятно, такая схема работы хорошо пойдёт, когда в приложении много сложной постоянной меняющейся логики, которая сдобрена небольшим кол-вом UI.
Глянул пример.
Я правильно понял, что UI для iOS всё равно придётся писать самому, но только уже на Java + всякие хелперы типа аннотации?
и языка платформы «1С: Предприятие 8» — золотой жилы для российских программистов

Откуда дровишки?)

Information

Rating
Does not participate
Location
Нижний Новгород, Нижегородская обл., Россия
Registered
Activity