Looks great. It certainly has become much easier to build such apps on modern Android :)
For something a bit more old school, I’d like to insert a shameless plug here that we open sourced something similar several years ago. It’s focused on the enterprise side, so setting it up is unfortunately quite a bit more involved. Screen rendering is obviously far less advanced as well, though still decent enough. It’s compatible with (almost) all Android versions since 2.3 which has its own fun challenges!
At first most of your users tend to be fairly advanced. After all, they've even managed to somehow find the obscure thing you've made. This is the most rewarding time for an open source project as many of the issues are real and the quality of bug reports and feedback is extremely high. Over time, as the project gains popularity, many of these issues will either have been solved, or have become easily googlable. Therefore you'll rarely hear from the advanced, intelligent portion of your users, although it's also certainly possible that they've already moved on to shinier things.
In the end, you tend to have a noticeable, vocal portion of users whom I'd generously call "social developers," who are bad at figuring things out by themselves and/or prefer asking things from another person to save a few minutes of their own time. Many of these users are very draining to deal with.
This matches my experience. Even now, depending on the day, I might be looking at around 30-50 emails of varying, usually depressingly low quality per day. I've had some relatively successful one man projects in the past and at peak popularity it would take me several hours per day to sift through everything.
I have one and I'm not using it anymore. It's quite possible that the software is more mature and usable now, but unfortunately it just wasn't good enough at the time. There were severe issues with DNS, with most requests taking a few seconds to complete, making simple tasks like browsing the internet quite infuriating. By default, there was no support for resolving local hostnames either, but it was possible to make that work by modifying some of the config-generating scripts to add a forward to another local DNS resolver. I don't recall the details exactly but there were at least two local DNS resolvers running due to missing DNSSEC support in one, and it may have been possible to enable a third resolver as well. Quite confusing.
I'm also not sure why they bothered adding their basic UI in addition to the OpenWRT side, it barely exposes anything and it was common to receive error responses. Maybe they just felt like they had to add more funding goal rewards.
The antennas were a bit loose but the case is quite easy to open, so they were easily tightened.
I now have Ubiquiti gear and the DNS delays and other issues are completely gone. While I in principle fully support the project, it turns out that I just wasn't willing to spend days customizing the thing to get it to work at a reasonable level, especially when my own daily internet use relied on it.
If someone feels like the current retail price is a bit steep but wants to give it a go, I've got my silver 2GB RAM model available for a more reasonable price :) It has the potential to be great in the hands of the right person.
I also have one of the first backer editions and I had no issues. DNS being slow sounds like a resolver problem. Like it's timing out for some reason. To be honest, I'd suspect your network rather than the omnia.
The thing that worries me the most with the Omnia is how well it's going to be maintained.
I had no idea it used OpenWRT at all, my impression was that they made their own OS based on Linux.
So that's essentially like its own distro. Hence my worry that it's not going to be well maintained with patches for the far future.
It's good to hear that at least some others have not had any issues :) It is certainly possible that the ISP modem may have been doing something special, but I've now been through at least 4 different routers of various grades over the years and sadly Omnia was the only one to ever exhibit that issue here. Or it may have had something to do with IPv6 or PPPoE. Hardwiring DNS to 8.8.8.8 did not help either. In the end I deemed it not worth it to waste any more time attempting to fix it.
Well I ended up buying an ASUS router, because OpenWRT's support for IPv6 isn't full on (The 6RD support really needs improvement).
There are some other things I would like to see, which I see people have been making scripts for some of those things (Time based firewall rules for example).
I have to second this. Got the 2GB version as well and it was a (big) downgrade from my previous router.
Same problems: DNS took ages, which lead to all requests/'the internet' feeling very slow. Switching hardware/going back improved the performance again, so I don't quite feel that the ISP or network was to blame.
As a side note, many Chinese brands have started preventing applications from starting automatically without being whitelisted in settings (different for each vendor). Examples include Xiaomi (since MIUI 8.1 or 8.2), and some recent ASUS/Lenovo devices.
Think of a front end developer working on a mobile site. Now, in an ideal world everyone would know how to set up an SSH tunnel, but let's be real here, even you probably have to look up the exact flags you're supposed to use every time you want to set up one. Combine this with the need for a publicly accessible server somewhere, and it should become somewhat clear that many simply do not possess the skills, resources, and/or couldn't be bothered to go through the trouble. With ngrok, you just download a single binary, make it executable, and you're ready to go. It's easy enough for most, although I suspect a GUI would further increase its reach.
Corporate policies often prevent employees from connecting their private phones to the internal network, so simply accessing the internal IP isn't really doable. You might be able to apply to have your device whitelisted, but that may take days, perhaps weeks, and even if you're approved, it doesn't really help as you cannot show your work to others (e.g. your team lead) without having their devices whitelisted as well. You might argue that everyone should have a company-provided phone with access to the network, and that's certainly a solution. Realistic? At most companies, probably not. You might have shared phones but who wants to work like that? Plus, there are developers who feel more comfortable playing with their own phones anyway. Regardless of which and whose device they have, they'd still be limited to WiFi only. Sure, you can emulate slower networks, but that's one more thing to know about. With a tunnel, you can see how the thing you're working on feels over a real 4G connection with no additional configuration. All this while developing locally with no need to waste time deploying to a separate environment.
That's just one use case where ngrok shines. The fact that you do not need to "correctly configure a firewall" is a selling point. Does it circumvent the firewall and expose machines on the internal network? Yes it does, and that's certainly a concern. But since people are people, perhaps you should have a similar, easy to use service available for your developers so that they don't have to resort to third party services you have no control over.
I'm not sure how you've interpreted the post that way. The point of that one specific thing was nothing more than to bring attention to the fact that even users who do have the skills to do this all by themselves often can't recall how exactly to get it all going without googling or reading manpages a bit, and that people who are less familiar with these things would be even less likely to know how to set up an SSH tunnel properly, or perhaps even know about them.
For example, even though I use SSH tunnels quite often, and can in fact remember the flags, I sometimes don't remember if the local or remote port came first. A minor issue for me perhaps, but I'm sure you can imagine someone getting stuck at some point, and having to bother a team mate to check what's going on, which is an entirely avoidable waste of time. You also have minor ops overhead for making sure the tunnel servers stay up and running.
In the end, aren't nearly all tech businesses about improving the user experience in some way? For example, you could set up your own mail server (and deal with the issues that come with it) instead of using Mailgun/Sendgrid, or take a taxi (or drive) instead of using Uber/Lyft.
It's intellectually dishonest to cherry-pick that and then ignore the part about having to have a server with DNS, fixed IP, public SSL configured, etc.
I believe the reason they continue selling them is so that companies with existing deployments can expand them with the same gear that already works for them. It's the same for most enterprise-oriented hardware.
You must not have been looking very hard. Searching for "email" on the policy page gives you:
> Responsibility for Your Site
>
> 5. You will not engage in any promotional, marketing, or other advertising activities on behalf of us or our affiliates, or in connection with the Amazon Site or the Associates Program, that are not expressly permitted under the Associates Operating Agreement. For example, you will not engage in any promotional, marketing, or other advertising activities in any offline manner, including by using any of our or our affiliates’ trademarks or logos (including any Amazon Mark), any Content, or any Special Link in connection with an offline promotion or in any other offline manner (e.g., in any printed material, mailing, SMS, MMS, email or attachment to email, or other document, or any oral solicitation).
Unless the user takes a concrete action to confirm the redirect, that is not allowed. Under Disqualified Purchases:
> (e) any Product purchased by a customer who is referred to an Amazon Site by a link that sends users indirectly to the Amazon Site via an intermediate site, without requiring the customer to click on a link or take some other affirmative action on that intermediate site (a “Redirecting Link”),
It can be slightly more complex than that if you use a package manager to publish your work. I once accidentally leaked a password due to having both a .gitignore and an .npmignore, and forgetting to include my .env file in the latter. Fortunately, I realized what had happened almost immediately and was able to change the password. Now I tend to `tar tf` everything before publishing.
Because of issues like this I tend to set up my deploy scripts to first `git clone` into a temporary directory, then do the rest of the work from there.
For something a bit more old school, I’d like to insert a shameless plug here that we open sourced something similar several years ago. It’s focused on the enterprise side, so setting it up is unfortunately quite a bit more involved. Screen rendering is obviously far less advanced as well, though still decent enough. It’s compatible with (almost) all Android versions since 2.3 which has its own fun challenges!
Anyway, great project with a modern take!
https://github.com/openstf/stf