rhardih

Wow, I literally wrote down an idea for a tool like this, just a couple of days ago.

I'm running OpenCV on Android for an app project, and gauging pipeline costs at different steps is a pain. Right now I'm resorting to a "timing" build, with basic printouts of elapsed times at each step. Archaic.

Do you guys plan to add e.g. Snapdragon etc. as a measure at some point?

Also are the benchmarks based off of real device numbers, or are they fuzzed estimates somehow?

You seem to target businesses, understandably, but I signed up for a beta in any case.

I've been using the free plan on Pingdom for a long time, and it's a great service! They've recently decided to scrap the paid plan however:

https://venturebeat.com/2019/01/07/pingdom-will-kill-its-fre...

I can totally understand the move, and if my personal needs were greater, I'd gladly have converted to a paid account. Basically I just want an email if one of my hobby projects goes down. Nothing much more.

I already pay for a server, so I decided to put together a minimal Rails app that gets me 95% of the way instead of hunting for another free provider.

For now there's no auth etc. It's bare bones, but batteries included. All you need to run your own instance, is a host running docker.

I wonder how much Google Books takes compared to Amazon and if Fabien considered other publishing platforms, with less egregious profit cuts.

When I say architecture, I mean running a full web-runtime as your core application layer. That is a fundamentally broken paradigm in my opinion. That's also the difference between RN and Flutter.

You're right. I didn't actually know that was the case. That makes inclusion in a project a much easier decision.

Tim Sneath linked to the official plugins list in another comment, https://github.com/flutter/plugins, and both camera, sensors and connectivity, would be akin to the kind of ownership I'd expect. It's definitely a good start.

Hey Tim. I can completely understand the reasoning behind it from a project development perspective, I'm just pointing out some of the pitfalls in doing it this way.

Obviously I don't know how you've structured responsibilities internally, but what I've seen before is, that the quality of individual components, or plugins if you will, live and die by the interest of the teams and people behind them.

Qt has this very same problem, often leading to some bugs ageing unacceptably long, or features never properly maturing, simply because there's little to no inside interest. NPM has a variant of the same problem as well. I'd venture a guess that a large percentage of packages on NPM right now, is downright abandonware.

I will be keeping a interested eye out for the developments of Flutter and I'm hopeful you succeed in this space. There's definitely room for it.

With regards to the native stuff, I'm mainly coming from a performance perspective on GPGPU and computer vision applications. I think going forward, there's going to be a huge increase in AR/MR apps, that will need easy access to do heavy lifting on metal. Coincidentally, I was lucky enough to catch a quick chat with Michael Thomsen, after his talk at Coldfront recently and he mentioned that, that was indeed on the roadmap. If you guys manage to provide the easiest cross platform way to do Vulkan/Metal or whatever the next-gen iOS and Android HAL is going to be, you're definitely going to come out on top.

WebAssembly on-device might be a game changer for performance critical apps. I'll happily welcome it when I see it, but I'm not holding my breath.

The thing is that most things coming from Web just moves faster, and there's so many more resources available for the 95% app. For all of that JS kinda makes sense. It just comes with a bad upbringing and poor manners, when seen through the glasses of considering a phone as an "embedded" device with resource restrictions. Performance is always seems an afterthought in most things web. And that's understandable, because even the baseline resource usage, as fast and small as you can get on a Javascript runtime, is still above what I'd consider acceptable. It just isn't for most apps out there and people have sort of gotten used to charging their phones mid-way through the day.

Qt definitely isn't perfect, and it can be a bit of a pain to work with. QtCreator is just... and there's no live reloading.

The good thing is that runs really fast on the machine you're already working on, so most of the time you just work on the Desktop windowed version anyway.

I wish there's was a bigger selection of UI frameworks available though. For mobile there's Qt Quick Controls 2, which is quite good, but not at all as expansive as what you have available on the web for instance.

I do think though, that if Qt doesn't do something about their tooling and ecosystem, that they'll get run into the ground when some of these other frameworks bridges the gap to some of the features that Qt is still unique in having.

When the mental burden of integrating existing libraries, through tons of wrapping/boilerplating, such as it is with JNI, starts to overshadow rebuilding the same thing, at your current application layer, it's close to a zero value proposition.

Disclaimer, I'm not a C++ guy.

I agree that a truly solid package system, is inherently a good thing for any framework. But it has to be just that. Qt is severely lacking in that aspect; qpm isn't even close IMO.

Counter to your point though, just take a look at the ecosystem around NPM for instance. What a mess...

For a cross platform development framework, to truly shine, I need to be able to "trust", that my majority use case is covered within the framework itself, so I don't have to go package shopping and spend a lot of time on quality controlling vendored code.

For a mobile app framework, I want the most ubiquitous device capabilities covered. That means various hardware specific things, such as networking, gps, bluetooth and yes, the camera. Whatever is to be expected present on most devices.

So yeah, I guess it boils down to dependability and trust. Something which is implicit in the framework and core library for the most part.

Yeah I know about https://flutter.io/docs/development/platform-integration/pla...

But, that's almost the same as not having support at all. JNI isn't really a poster-child of usability.

With Qt, since you're already on the right side of the fence, it's just a matter of "#include "whatever.h" and linking it at compile time.

I mean, even just getting a camera feed on Flutter isn't a built-in: https://pub.dartlang.org/packages/camera

Flutter appears to have a lot of the momentum that other frameworks lack. I've usually sworn to Qt/QtQuick, but only because I want to be able to easily jump into native code, and/or reuse existing C/C++ libraries, even on mobile devices. Flutter can't do that yet afaik. Qt just isn't going in the right direction. IMO if they'd gotten their act together, even years ago, all these new fangled X-Platform frameworks, wouldn't even have existed.

I have to admit, that I haven't really taken RN seriously, because I fundamentally don't believe in that architecture on a mobile device. RN only seems exist to provide a means for people who like React. Not to actually provide a beneficial application framework.

I'm stealing that for .bash_profile! It get's a spam marking right away, but useful nonetheless!

Same. No touchbar, io of the 2015 model, card reader, usb, headphone etc. Plus Magsafe.

Basically the '15 model with improved battery, cpu, memory and hdd.

I'd buy one today if I could!

It's a down period closing on three years, and Apple have yet to even indicate a change of course.

This might unintentionally be, the funniest satire project I have seen so far!

That would be an awesome feature, but would mean sticking your hand into the whole data-collection/user privacy/GDPR rats nest. Not a ship I'm too keen to captain.

> This is half-baked

Half baked is an understatement, but I guess it works sorta-ok for a half-day project. Pull requests are very welcome though!

I use it to feed my pet rock and now it's never hungry!

Someone opened an issue with just such a thing:

https://github.com/rhardih/ekill/issues/1

Would you look at that. I've actually been using uBlock since forever, but had no idea it could do that. Oh well, I guess sometimes you just can't see the forest for trees.

Can anyone explain to me in layman terms, how this is legal? I mean charging money for freely available open source tools, not owned by this site?

I'll take an Android promo as well!

Pretty cool, but straight up turns your laptop into a radiator.

That actually sounds like a great approach! I can imagine you've triggered a sense of involvement or idea ownership in the most active ones. From my own experience, as a user, reporting a bug er suggesting a feature in a product, only to see it fixed or added, has a tremendous effect in loyalty and even promotion of said product. I think I'll definitely adopt this idea once properly released.

That's currently where I'm at myself. Do you feel that, that approach scales fine and you get a broad enough idea of where problems are for the general user and where you need to improve/change things?

I agree, it's easier to do for web apps since you don't have to contend with "app store reviews", that can potentially leave a lasting blemish on your product. So far I've done it as you describe as well and it's the "getting enough users" part that's a pickle. If you get X users on to sign up for a beta, only a fraction of those will actually ever install the app and give it a spin and again, only a fraction of those will give you any real feedback to work from. Finding real testers without breaking the budget, of your (maybe zero-profit) app is the challenge.

Post-launch is mainly vetting that new features makes sense to users and catching UX faux pas, instability or even crashes, etc. before opening up to a wider audience, and possibly scores of bad reviews.

I was thinking about just opening up on the app store as well, and just sit back and wait for reviews or emails, but that seems risky, since potentially bad reviews are forever. For a paid app at least, that can have a pretty serious impact on possible uptake. Having at least some level on confidence, that the app is usable and stable before general availability, is the safe play I think. To that affect, closed testing seems the only viable option.

Mostly true, except with BitTorrent you get tricks for NAT traversal that WebRTC will never have and failure is an option. It works without a STUN/TURN central server, as long as the swarm is sufficiently connected.

Seconded. This seems like a major step back for x-platform GPGPU. I always just assumed a natural transition from GL, CL support to Vulkan would occur at some point, but this is just a shame.

Nice idea, but you should probably add links to a github project on the presentation page.

I doubt you'll get anyone to just download and run an app, without at least taking a glance at the source first.