Контакты

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (35)

Лучшие ответы пользователя

Все ответы (39)
  • Android: Qt vs Java. Что лучше использовать?

    @dplsoft
    Посмею оспорить ход рассуждений lorus ( Android: Qt vs Java. Что лучше использовать? ).
    Итог у нас почти один, но как в математике - когда ход рассуждений ошибочен - даже если ответ верен - то задача не решена. Возможно во много субъективно, но выскажусь, на правах личного мнения человека, который любит и писал и на Qt, и на Android с его "родным" Java тоже.
    На Qt для Android не писал, потому что на момент начала последнего проекта технология была сырая.

    И так: Не агитка за Qt но несколько слов в защиту Qt.

    Забегая вперед скажу: топикстартеру - если есть небольшой опыт разработки под Андроид, вы не работали ранее с Qt, и вам не важна переносимость исходного кода между всем и вся - продолжайте осваивать Android SDK ( Java ) .
    По крайней мере, сейчас.
    Хорошее знание хотя бы одного инструмента, лучше чем посредственное знание двух. ;)
    C Qt под Андроид потом разберетесь. Да и "пообкатаннее" оно будет.


    1. Qt - это всё-таки C++. Разрабатывать на нём существенно сложнее, чем на Java. То есть дольше и с большим количеством ошибок.

    Надо отличать "просто С++" и С++\Qt. В первую очередь, Qt - это фактически диалект языка С++. Например в объявлении Qt-класса появляются дополнительные секции signal и slots, а в процессе сборки существует фаза мета-компиляции, которая делает C++ код под вашу платформу. Не удивлюсь, если для андроида генерируется сместь Java и C++ кода которая потом скармливается Android NDK.

    Во вторых, Qt - это _самодостаточный_ фреймворк. Никаких STL или "чего-что-ещё что представляют себе в комплекте с C++" типичные сторонние разработчики.
    Многих проблем, которые приводят к сложности разработки "на простом C++" в "С++\Qt" просто нет "by design".

    Например в Qt заложен замечательный механизм предотвращения от выхватывания "null-poiunter" - "сигнал-слоты". Это в разы упрощает и делает надежнее работу как с GUI, так и с например, объектами, работающими в разных потоках. В Qt это все сделать разы проще, чем городить аналогичные стандартные механизмы на Java. Я не говорю в итоге оно будет эффективнее - тут надо выяснять и можно поспорить - но вот то, что в Qt многие вопросы работы с потоками и межпоточным взаимодействием продуманы лучше а механизмы удобнее - на мой вгляд это факт.
    (Хотя вот такого классного механизма аки runnable, в Qt нет. Но ждем 11-го стандарта С++.)

    В третьих - "С++\Qt" - это хорошо продуманный фреймворк едва-ли не с лучшим дизайном классов, продуманными методлами, единым стилем решения проблем.

    Как человек писавший на Qt 4.0-4.6 и сейчас закончивший первывый коммерческий проект для Android - могу выставить в сторону Java много минусов (в сравнении с Qt4/Qt5.) Просто потому, что Java - как в первую очередь коммерческая технология, был вынужден набирать нелогичности ради совместимости с предыдущими версиями - едва-ли не из первых версий Java. Посомтрите вопросы к сертификации - много вопросов, которые когда начинаешь разбирать "почему так" - уходят корнями в далекое темное прошлое развития Java. И в итоге - современная Java - это часто нелогичное, лоскутное одеяло, где в разных классах для решения одной и той-же задачи применяется если не разный подход и стиль, то как минимум разные имена методов. Ну вот зачем это?)))

    Да Java детально описан, и в технически прогнозируем - но его надо зубрить, тупо зубрить все исключения и проблемы наследования логики первых версий, и зубрить где используется put(), а где add()....
    ... а Qt-можно _понять_ и не зубрить, понять и только изредка заглядывать в документацию. И в итоге писать на нем - легче.

    К слову: дизайн классов гуглековских классов - хотя и очень-очень-оченьсвоеобразен и местами диковенен, но он, имхо, достаточно "строен" и в общей совокупности, не страдает такой уж сильной лоскутностью логики, какая имеется в стандартных классах Java. С какого-то момента ты понимаешь "как думали в гугле" и все становится несколько проще.

    Ещё к слову про миф "на Java писать проще чем на C++"(если сравнивается Java под DalvikVM и C++\Qt5):
    Не забывайте - DalvikVM - это вам не JavaVM.
    В DalvikVM вы легко отхватите "null-pointer-exception" если вы вдруг наивно думаете, что коли у вас есть в локальной переменной ссылка на фрагмент, активити или вью - то машина не уничтожит объект "когда ей вздумается", а у вас ваша переменная не об-null-ится.

    На понимание того, какие привычки десктопного написания и дизайна приложений нельзя переносить во фреймворки Android SDK и на перестройку собственного мышления - у вас уйдет несколько месяцев. А вы _начнете_ это понимать и отхватывать такие проблемы - как только начнете писать что-то бОольшее, чем набор разрозненных активити да пары фрагментов из учебных курсов.
    И в итоге - первый ваш серьезный проект на Андроиде - может влететь вам в хорошие переработки.
    Например, в том числе и потому что нет в Android SDK v17 жизненного цикла для класса Application. Нет механизмов для созранения состояния singleton-окружения и тд.и тп.

    А когда вы пишете на Qt - у вас гарантирована поддержка единых механизмов для всех платформ.
    Вам не надо перекраивать мозг, выработанные решения и отлаженные и проверенные паттерны.
    В итоге - писать на Qt - может статься и будет быстрее. В ряде случаев.
    Но из Qt - может быть сложно поиметь доступ к сугубо-андроидным сервисам типа поставщика данных.

    В общем я к чему. нет тут однозначного ответа что лучше а что хуже.
    Каждый инструмент достаточно мощный и у него много плюсов, минусов, и особенностей.

    2. Инструментарий разработки для C++ однозначно хуже такового для Java в силу, опять-таки, особенностей языка.

    Простите, но тоже малообоснованное утверждение. См пункт 1.

    Кроме того, отмечу:
    Qt-шный инструментарий позволяет вам получать одинаковое поведение на всех поддерживаемых платформах. Включая поведение GUI, Форм и одинаковую для всех систем архитектуру приложения. В идеале - с Qt - вы можете писать под Андроид так, как будто вы пишете под десктоп - не меняя архитектуру и структуру приложения.

    А когда вы пишете под Android на Java - вы всегда пишете кусок кода работающий в колнтексте DalvikVM и должны жить по предусмотренным данной машиной паттернам и сценариям, причем многие аспекты того "как это работает" - явно мало где прописаны. И если вдруг вы отсутпаете от стандартных шаблонов фреймворка Dalvik-машины - вы рискуете отгрести непонятные, трудно отловимые косяки, причем _вне_ вашего контроля, которые вы не можете корректно перехватить и обработать. Кто не знает - попробуйте уничтожить ViewGroup, id которого вы использовали как контейнер для размещения внутри него фрагмента. Как только вы делаете FragmentTransaction.commit() - вы ставите машине задачу, которую она будет выполнять "когда-то позже", вне вашего контроля, и не соизволит позволить вам корректно обработать исключение. Вплоть до возникновения ситуации, когда фрагмент пытается быть добавленным в Activity который уже отработал стандартные процедуры по Activity.finush(). Ладно бы оно выкинуло код ошибки куда, и тихо проигнорило - но это же Java - она выкинет исключение. А обернуть это дело в try...catch - вы не сможете - это не ваш кусок кода. Максимум что вы сможете - это "поймать перед смертью" Thread.UncaughtExceptionHandler. И все.
    (если я не прав - поправляйте меня, я же тоже не инженер гугля)

    3. Java - родная платформа для Android. Отсюда потенциальные проблемы с совместимостью у Qt.

    Вот зачем вы занимаетесь запугиванием?
    Android NDK (для разработки на С++) такой же родной как как и Android SDK (для разработки на Java).

    И с совместимостью у Qt с платформой Android проблем не больше, чем у любого другого приложения, которое использует вставки C++ кода и разработано с использованием стандартного Android NDK.

    --------------------------------------------
    Резюмируя: автору надо просто взвесить что зачем и как он собирается использовать.
    Если автору нужно одинаковое поведение на различных платформах - включая огрызочные поделия, Linux, разные Windows RT недопланшеты - то выбор ознозначен - курите Qt. Это возхитительнейший, ясный, хорошо продуманный и максимально логичный фреймворк, который не побоялись пересоздать с нуля ради устранения накопленных сложностей (вспоминайте переход с Qt3 на Qt4) Лично я приходил в восторг, когда работал с ним (2005-2009 гг)

    Но - в части Андроидного приклада : подозреваю, могут быть "технические риски" с использованием каких-либо особых "мобильных кусков" типа "работа со звонками, "работа с контактами", "работа с почтой" или "поставщиками контента", и пр.
    Я отошел от мира Qt когда Qt был 4.8 и я не искал там классы которые этим занимаются. Думаю что-то потомки троллей должны были создать в 5.2, но лучше проверить.
    В крайнем случае - может потребоваться стыковка с джава-объектами, и тут вам потребуется изучать Android NDK, и возможно даже писать немного оберточного кода на Java.

    Если же вам _нужна_ обязательная работа с описанными выше функциями, а на переносимость исполняемого кода - наплевать, или же у вас _уже_ есть опыт разработки с Android SDK - то конечно писать лучше на Java.

    Но в этом случае бутьте готовы к тому, что это не JavaVM, и сохранности ссылок _для_ряда_классов_ вам никто не обещает, а т.к. Java не предполагает наличия деструктора - вы _будете_ иметь определенные архитектурные сложности при построении сложных приложений.
    Например то, что в десктоп-приложении вы решили бы "простым" "синглтон-объектом" с простой функциональностью типа записал-прочитал из файла - тут вам _придется_ решать путем построения "поставщика контента" и т.п. - что значительно повышает "порог входа" для тех кто погруждается в разработку для Android.

    Но - надо отдать должное инженерам гугля - у них _были_ весомые основания поступать итак, и они максимально вас обезопасили от попадания в многие проблемы - если, конечно, вы используете фреймворк именно так, как это предполагается. И сделали многие механизмы достаточно элегантными, и приятными в использовании. Дизайн гуглековских классов мне в большей части нравится. В общем не забывайте понимать почему в примерах делается именно так как делается, а не иначе.
    Ответ написан
    5 комментариев
  • Переход с Angular на React. Тренд или нет?

    @dplsoft
    в следствии успехов маркетологов одного или другого лагеря.
    и смены моды.

    хотите совет от инженера ? "узбогойтезь" и прекратите искать смысл тараканьих бегов в головах приверженцев моды. мода на реакт уже проходит; фап на вуе закончится через год, сменившись очередным "откровением", которое в свою очередь подохнет вытесненное очередным фапом по новому откровению.

    и произойдет это быстрее, чем вы успеете даже понять разницу между "устаревшим" и "самым трендовым".
    и на вопрос "а зачем отказываться от устаревающего, если это работает и выполняет нужные нам задачи" - вам никто внятно, технически обоснованно не ответит. вам начнут втирать дичь про синтаксический сахар, про "правильную" реализацию mvc, про реактивную связаность и что она везде как лучше (вот уж поверьте, не везде), что это "правильная магия" и более прогрессивный подход, и т.д. и т.п.

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

    ну так вот: разница между 99% фреймворков джаваскрипта - это куча чепухи и рассказов про то как тут все клево, прогрессивно, моложежно. и практически ничего технически обоснованного. да, структуры разные, апи разный, но эта разница отражает как правило только вкусовщину их авторов и весьма редко имеет под собой хоть какую то техническую необходимость.

    потому что это МОДА.
    "не пытайтесь понять тараканов".

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

    они всего лишь пытаются увеличить круг потенциальных соискателей и привлекательность вакансии в глазах неразумных.

    они надеются что модники следящие за трендами, но остаюшиеся на "старых технологиях" собласнятся сменить работу под обещание, что они плавно вольются в новый фремворк, на новой работе.

    ... ps: а jQuery при этом продолжает и продолжает выполнять 90% всей черной работы на 90% всех сайтов ;)
    Ответ написан
  • Разработчик недисциплинированно трекает время. Что делать?

    @dplsoft
    вы, если вы хороший менеджер, вы должны, наверное, понимать, что недоверие и чрезмерный контроль - становятся слишком накладными в плане трудозатрат. почитайте почему в китае работает практика "ту-ань-ши" кажется, когда в громадной компании всего 3 уроня управления - и у каждого менеджера по 40 замов, и почему этого нет в американо-европейской практике, где 1-2-3 зама - это "норма", и в итоге управленческий аппарат раздувается на множество слоев.

    с разрабами нечто похожее. хотите точных отчетов - не доверяете им в некотором смысле, т.е. не верите, что они занимались чем то полезно осмысленным - вы будете тратить все больше и больше времени на эти самые отчеты и механизмы их обеспечивающие.

    и будьте готовы к появлению графы в трудозатратах "заполнял журнал трудозатрат, 1 час в день".
    более того, вы должны эту графу предложить. как минимум потому, что хороший руководитель проекта всегда выделяет в wbs отдельную графу работ под разванием "управление проектом". и в вашем случае, заполнение детальных отчетов о затратах на задачи - это как раз "управленческие расходы".

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

    вы сами то понимаете, какой толк, какая практическая польза от максимально детализированных отчетов?
    почему вас не устраивает скажем 10% погрешность в этих значениях?

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

    и более того - это как раз и есть ваша работа как менеджера - следить за этим.
    если бы все люди сами все делали автоматически и честно - тот же фрилансер всегда сам правдиво, точно и по расписанию все заполнял - вы стали бы ненужной прослойкой.
    Ответ написан
    1 комментарий
  • На чем писать веб приложения с GUI как в desktop app?

    @dplsoft
    вставлю свои 5 копеек. сумбурно, не все совсем все по теме буду излагать (но там будет ответ на вопрос .. вроде как) но надо понимать область применимости того, что хочет тов. Евгений .

    Его желание "писать в веб так как десктоп" - мне очень даже понятно, и именно поэтому я фактически сделал свой фреймворк ( не на джаваскрипте, что вы, джава+вебсокеты, и совсем немного js). Но его область применения - тяжелый интерпрайз и интранет.

    т.е. писать приложения с веб-интерфейсом, используя подходы и концепции "как для дексктопа" - это иногда просто необходимо (сейчас веб интерфейс в браузере - это уже практически стандартное требование для корпоративных систем)... НО совсем нельзя, ни в каком случае нельзя так делать если вы собираетесь писать массовый веб-сайт "в паблик".

    ну и наоборот: современный модно-молодежный подход с тяжелым js, рест-сервисами , микросервисы, stateless-подход и тп - это хорошо ровно до тех пор пока у вас не начинается тяжелая бизнес логика, сложный арм какого либо оператора или необходимость быстрой его адаптации.

    и так. имхо, есть 2 направления, сложно совместимых идеологически друг с другом. ( 90% "веб разработчиков" скажут, что есть только одно... но и фиг с ними - они не знают, а я излагаю свое имхо-мнение системного архитектора, чей стаж в it зачастую больше, чем весь возраст упомянутых чуть ранее "веб разработчиков" ))).

    и так. "массовый веб" и "тяжелый интерпрайз" :

    1. массовый веб.

    тонны хомячков, тысячи примитивных запросов, простая логика (бизнес логика). на это заточено 120% современных веб-фреймворков, которые соревнуются между собой в синтакс-засахаренности, да функционально-фиче пригодности. микросервисы, stateless, rest-сервисы, json-туда-обратно - "... о как.. всем прияно...." и т.д. 90% последователей этих технологий не понимают даже основ проблем разработки больших систем на языках с динамической типизацией, готовы топить за самый модный в этом сезоне фреймворк, давить статистикой новых проектов на гихабе.... но да и фиг с ними, ... достаточно того, что те-же "хедлайнеры" - node.js - вдуплили эти проблемы и таки послали js подальше... тьфу - перешли на typeScript ( ибо статическая типизация - этт не закостенелость стариков, а вынужденная мера, совсем "не от хорошей жизни")... но тысячи хомячков любящих js ведь не могут ошибаться... и потому плодят мирриады js-фреймворков, каждый из которых применим в 2х случаях из 100. и отслеживают топ 10 попутярных в этом квартале языков программирования... ну ла ладно.

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

    примеры: вконтактик, форумы, и 99% всех веб сайтов.
    типичные технологии: php, одноглазый змей-питон, js, чудо руби, и все прочее и тд....

    ps: и да, я ни коем разе не хаю js. я его люблю. но крайне рисковано применять js в объеме большем чем скрипт на 2 страницы. первый же рефакторинг и переаботка кода поломает все нафиг. на определноом объеме кода вы попадете в ситуацию, когда попытка имправить баг будет вность еще больше багов и вы не сможете это остледить.
    то, во что сегодня превратили js и технологии на js - это страх и ужас, но да это моё имхо.


    2. интерпрайз интранет
    ...и различные АРМ с веб-интерфейсом в локальной сети и сложной бизнес логикой

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

    примеры: СЭД (системы документооборота), арм различных госструктур, арм различных операторов, и тд.

    вот тут как раз все наоборот. одна только попытка использовать stateless подход и тяжелый толстожЁпый js грозит вам переработками такого масштаба, что вам и не снилось. т.е. вы конечно построите первую версию и все у вас будет хорошо... до первого рефакторинга и отработки замечаний заказчика по новой версии регламента, которая была утверждена руководством месяц назад... (ну а вы начинали работу конечно полгода назад, и вот уже вроде как через месяц надо было бы сдаваться)... но внешние условия изменились, и у вас начинаются проблемы, вырисовывается громадный объем работ по рефакторингу. просто потому что крайне сложно сделать машину состояний и сложную логику диалога с веб-клиентом, в ситуации когда вы постоянно терятее состояние процесса на сервере... а вы попытались написать внутренний арм как будто это сайтик ...

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

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

    за spring мало что скажу, но сколько я видел - он тоже не решает проблем написания сложных-веб-интерфейсов. много вкусного для серверной части, но для общения с вебмордой в конце концов все опять скатывается к rest-сервисам, аякс-json-туда-обратно и тп. - что, повторюсь, при усложнении логики работы вашего арм сильно вдарит вам по самым нежным и мягким местам раскаленной булавой.

    в общем вот тут идеи десктопного приложения очень как пригодились бы, но готовых технологий нет.
    я вижу перспективу в использовании web-socket, но опять же, промышленных наработок и фреймворков нет.
    самое близкое что так умеет - c++/Qt но у них скорее трансляция в веб интерфейса с++ приложения. в 1С аналогично - у вас одинаковый интерфейс "управляемой формы" и в веб и на десктопе.

    у нас есть свои домашние заготовки, но, повторюсь, мы пока их не выпускаем на массовый рынок, предлагать не буду. погодите полгодика, и все будет.

    ---------
    в общем я к чему: хотите использовать десктоп в веб? пишите например на qt/c++. у них есть технология трансляции в веб приложения написанного на c++. опять же, на вебсокетах все работает). хотите писать тяжелые арм на джаве для интарнет-интерпрайз-систем - присоединяйтесь к нашему закрытому тестированию (за сим в личку) или ждите публичного анонса. для шарпов ничего не скажу, имхо шарпы только для Unity-гемдева и пригодны(имхо), а как интерпрайз-технология они так и не состоялись.

    если хотите писать массовый веб - концепции десктопных приложений вам совершенно не пригодны. вы , банально, слишком много израсходуете ресурсов при относительно малом наплыве пользователей. никто, например, терминальный сервер в публичный веб анонимусам не пускает. разорвут как тузик грелку.

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

    - "массовый веб" (тонны простых маленькиз запросов, сотни тысяч пользователй) - и никаких десктопных концепций не применимо! но зато тысячи идей и подходов, мирриады фреймворков, каждый месяц что-нибудь очередное новое модно-молодежное с тысячами фапающих на это хомячков... бурление масс, так сказать... главное не ходить с этим в интранет...

    или

    - "тяжелый интранетовский интерпрайз" ( несколько сотен пользователй максимум, сложная логика работы каждого АРМ, тяжелые запросы отрабаиываюшие по десятку минут, запутанные бизнес-сценарии рабрты гуи, фоновые процессы на сервере.... ) - многие десктопные концепции, когда гуи должен рассматриваться так, как будто он локальный - просто жизненно-необходимы. попытки строить эти системы по технологиям из области "массового веб" - ... скажем так ..."чреваты" и в 90% случаев пооучаются либо костыльно убогими, если вообще работают, либо неповоротливыми в разработке и рефакторинге. не смотря на это, готовых решений и концепций всё еще пока практически нет, каждый изъгаляется как может. рынок достаточно закрытый, относительно массового веб : 99% этих арм и ас работают в наглухо изолированных от интернеса сетях.
    Ответ написан
    6 комментариев
  • Как проверить определена ли переменная в js?

    @dplsoft
    единственный известный мне способ отличить глобальную переменную
    со значением undefined, от несуществующей переменной - это попытка присвоить её значение другой переменной. Вылетает исключение, которое мы перехватываем.

    Причем надо пытаться взять значение самой переменной ( VAR ), а не через window ( window.VAR )

    try { var aa=VAR; } // если тут отхватим исключение - значит у нас нет переменной VAR
     catch(e) { VAR =undefined; };  // присвоение  undefined значения - _определит_ переменную
    
    // и далее её можно использовать 
    var bb=VAR; // тут уже не вылетит исключение
    Ответ написан
    Комментировать