try {
data = parseAsFirstDataType(someFile)
} catch() {
data = parseAsSecondDataType(someFile)
}
Те считалось, что если не удалось распарсить файл первым типом, то второй тип парса обязательно спасет. (Наткнулся на код, когда не мог понять почему приложение падает, а исключения нет)
Прекрасный доклад. Очень доходчиво и ясно объясняет, почему нельзя просто взять и сунуть код в цикл и измерить производительность. Хотя после доклада я совсем не знаю как можно более-менее точно сравнить производительность кроме как по временной сложности алгоритма.
обработку then можно почти всегда опустить, а вот catch все же нужен. В браузере вполне приемлемо использовать такую конструкцию и при желании можно прокинуть нормальный обработчик
window.onerror = e => {
// тут может оказаться нормальный обработчик
console.error(e)
}
(async () => {
// ...
throw new Error('catch me')
})().catch(onerror)</source>
Статья с слишком провокационными заявлениями. Тут всеми силами выпячиваются достоинства фабричных методов и принижаются все их недостатки, в то время как классы всячески осуждаются и все их недостатки раздуваются. Самый яркий пример:
Фабричные функции содействуют использованию композиции вместо наследования, что даёт разработчику более высокий уровень гибкости в плане проектирования приложений.
, при том что это абсолютно такой же не менее популярный метод и в случае классов, однако «более гибкий», хоть и ограничивает один из подходов. Пункт про безопасность тоже особо весомым не нахожу, ибо если кому-то действительно сильно надо влезть в контекст замыкания, то он может воспользоваться грязным хаком через Function.prototype.toString(). И самое удивительное неужели человек склоняющий к функциональному программированию высказывается против стрелочной нотации которую повсеместно для этого используют. Статья была бы хороша как сравнение подходов, но в итоге в конце она превратилась в сплошное осуждение классов.
Не соглашусь. Gear VR это все же решение для телефона со всеми вытекающими. Общего у них только андройд. Просто в угоду плюшкам этим порезалась производительность, но исчезают провода требование к дорогостоящему компьютеру и настройке оборудования и негромоздкие контроллеры(6DOF пока в разработке, он будет анонсирован в будущем)
При этом преимущества сохраняется румскейл
Но стоит признать, что на данный момент для разработки он является тем еще гемороем
Ниже я уже написал про HTC Vive Focus. www.vive.com/cn/product/vive-focus-en
Беспроводной и отлично сидит на голове. Никакого лишнего оборудования и мощных компов (по сути, подход разряда консолей в мире VR). Никакой настройки оборудования благодаря инсайд-аут оптическому трекингу. Контроллеры не громоздкие а крайне компактные(пока 3DOF, но вскоре будет и 6DOF и для него тоже не понадобятся внешние оптические системы).
Разработка ведется в этой сфере крайне активно, поэтому ждать особо долго не придется
Vive уже представил версию Vive Focus, которая без каких либо проводов, правда пока с 3DOF контроллерами. Продажа ныне только в Китае, но надеюсь вскоре дойдет и до других стран
Работать сидя с VR? Что-то малоприятное занятие. Уже имели опыт создание виртуальной клавиатуры, но стоя: руки жутко быстро устают, даже при наборе свайпом. Так что такая разработка будет уместна только в специфических областях.
Пререндеринг скорее как возможная оптимизация для статичных страниц, поэтому ее считать устаревшей не совсем верно. Зачем мучить сервер заставляя генерировать его одно и тоже?
Был где-то сайт, где проверялись приемы и подходы и как это влияет на поисковики. Попробуйте поискать, но насколько я помню SSR дает значительно лучший результата, так как даже при выполнении JS они не дожидаются многих асинхронных функций
Мне интересно, на каких моментах себя на этой мысли ловили. VCL позволяет быстро набросать форму, но вот в какой-то более менеее сложный UI, а уж, упаси боже, анимации на нем раз в 5 сложнее реализовываются.
Насчет Qt+QML говорить не стану, так как опыта работы с ним даже года нет, с VCL работал около 4ех лет и сказать, что с ним больше не хочу иметь дела, значит ничего не сказать, Сpp+VCL вообще штука не самая приятная, а Delphi как язык меня в результате развития не устроил, FMX был хоть и сырым но более приятным для более сложных GUI. Возможно для сложных программ для работы с СУБД я бы и предпочел VCL/FMX, но не более.
А чем проверенная связка HTML+CSS+JS вам не угодила понять не могу, возможно, только отсутствием визуального редактора.
Не стоит забывать, что Eдectron не только Chromium, но и Node со всеми отсюда вытекающими: работа с файлами, взаимодействие с ОС. Поэтому слова, что мы получаем тот же браузер не совсем верны. А вот насчет надбраузера, так на нем его уже сделали: Brave(правда там форк Electron-а и цели несколько иные нежели чем у обычных браузеров).
Если уж кому-то совсем в край извратиться тот же сервер можно для управления обернуть Electron-ом(но это надо уж совсем извращенцем быть)
Главная причина, почему Electron настолько популярен: не нужно переписывать уже написанное. Имея уже веб приложение, вам не потребуется много сил для натягивания его на Electron. Если же делать десктопное приложение с 0, то вам не придется искать новых специалистов. Берем имеющихся веб-разработчиков и усаживаем их за Electron и кошелек доволен и скорость разработки высокая. Например, тот же Slack так и поступил. Про легкость создания и настройки UI говорить не стоит.
Главным же недостатком Electrone является его прожорливость и большой вес даже минимального приложения. Я вижу такой путь к решению проблемы: завозим Electron в качестве VM, а exe-шник приложения по сути его запускает и скармливает нужные данные. И получаем сразу -90% от общего веса приложения (даже если от проблем с ОЗУ это спасет не особо, то компактность увеличит значительно), а о проблеме с ОЗУ надо уже отдельно думать.
То самое чувство, когда у нас это может звучать на полном серьезе вот так:
Уважаемый отдел софтвара. На утрненнем митапе мы с вашим тимлидом приняли решение, что ASAP надо закрыть таски, по которым просрали дедлайн. Если вы не видите эскейпов, то можете обратиться по вопросам тайменеджмента и мы попробуем найти решение, предварительно получив добро у ваших лидоов
Сталкивался с кодом уровн:
Те считалось, что если не удалось распарсить файл первым типом, то второй тип парса обязательно спасет. (Наткнулся на код, когда не мог понять почему приложение падает, а исключения нет)
Да и отрицательный ноль — вполне самодостаточное число в мире чисел с плавающей точкой
А где тут IIFE? Да и то сократить можно
Если забыли добавить (). То это костыльный способ заменить do exressions
Прекрасный доклад. Очень доходчиво и ясно объясняет, почему нельзя просто взять и сунуть код в цикл и измерить производительность. Хотя после доклада я совсем не знаю как можно более-менее точно сравнить производительность кроме как по временной сложности алгоритма.
Тем, что исключения ловить обязательно
обработку
thenможно почти всегда опустить, а вотcatchвсе же нужен. В браузере вполне приемлемо использовать такую конструкцию и при желании можно прокинуть нормальный обработчикПри этом преимущества сохраняется румскейл
Но стоит признать, что на данный момент для разработки он является тем еще гемороем
www.vive.com/cn/product/vive-focus-en
Беспроводной и отлично сидит на голове. Никакого лишнего оборудования и мощных компов (по сути, подход разряда консолей в мире VR). Никакой настройки оборудования благодаря инсайд-аут оптическому трекингу. Контроллеры не громоздкие а крайне компактные(пока 3DOF, но вскоре будет и 6DOF и для него тоже не понадобятся внешние оптические системы).
Разработка ведется в этой сфере крайне активно, поэтому ждать особо долго не придется
А чем проверенная связка HTML+CSS+JS вам не угодила понять не могу, возможно, только отсутствием визуального редактора.
Если уж кому-то совсем в край извратиться тот же сервер можно для управления обернуть Electron-ом(но это надо уж совсем извращенцем быть)
Главным же недостатком Electrone является его прожорливость и большой вес даже минимального приложения. Я вижу такой путь к решению проблемы: завозим Electron в качестве VM, а exe-шник приложения по сути его запускает и скармливает нужные данные. И получаем сразу -90% от общего веса приложения (даже если от проблем с ОЗУ это спасет не особо, то компактность увеличит значительно), а о проблеме с ОЗУ надо уже отдельно думать.