In my experience it also depends on the worker type, if you are running sync you might need more workers depending on how much your database can handle.
Otherwise the number of workers might limit the total throughput quite severely.
Always interesting to test out a new productivity app in the search of the perfect solution :-) Looks promising! Really like the clean layout.
A bit of feedback: (maybe a bug?) when I tried to add new tasks to "Today", tasks added after the first task did not have the current date set and therefore did not show up. (At first it seemed like saving tasks did not work.)
Yes; gevent does also fix this problem. But it also gives you a lot of new problems when running all requests async. In my experience mostly with views that (in some specific calls, i.e for a specific customer) keep the cpu tied up, for example serializing a lot of data. Random other requests will be stuck waiting and seem slow while it is a lot more difficult to find out which view is the actual problem.
I have deployed applications both under gevent and sync workers in gunicorn and would personally never use gevent again, especially in bigger projects. It makes the behavior of the application unpredictable.
> Continuously failing external requests should not make each one of your responses slow.
It is not really a matter of the responses becoming slow, the problem is that if you are running sync with i.e 6 application server processes and you have just 6 hits on an endpoint in your app that is hung up on an external API call your application stops processing requests altogether.
Well, if you have external API calls in your Django app and you are running sync (which I would absolutely advice, with running async it is really easy to get an unpredictable performance which is sometimes hard to track down) having the ability to run some views async is really crucial.
Otherwise your application might me humming along smoothly at some point and coming to a sudden complete standstill or performance plummets when a random external API endpoint starts to time out. Yes I have been bitten by this :-)
To fix this while running sync I have dedicated separate application processes for the views that do external calls, but this makes the routing complex. Alternatively you can juggle timeouts on the external API calls but this is hard to get right and you need to constantly keep track if calls are not timed out just because the external endpoint is a bit slower at some point.
So I think this solves a very real-world challenge.
I think the confusion for me was that there is also a pay-per-word price; then for me the limit on the number of phrases does not feel logical. Phrases as tr() calls for me as a developer also depend quite a bit on how I have setup the translation and differ per project.
I would expect to pay a monthly fee for the online service + a fee for each word. Also, 100 unique tr()'s seem a bit limiting? (even smaller projects for me quickly get > 1000 separate tr calls)
I also do not understand the Linked-in notifications at all. They send an e-mail like '5 job changes' which I actually find interesting to learn about.
But when I click any of the links this information is nowhere to be found. So after a while I don't click on the links anymore and my engagement goes down.
Seems like a lot of the decisions are focused based on quick-wins engagement instead of an long lasting useful experience for the user?
We are running a (very niche) platform + app for people with special needs, where accurate and offline alarms are necessary: this is a big problem for us.
I think about 1/3 of all our support requests are about the app being killed in the background on specific phones. The part of the app that does the actual scheduling of the alarms is a big mess with lots of device & API level exceptions. Debugging alarm problems is a nightmare.
We often advice users on what phone to buy and tell them to avoid specific brands. Sometimes users even need to buy a new phone to be able to have reliable alarm signals.
I understand why manufactures are doing this. But it really degrades the user experiences for our users quite a bit and is a significant cost (in terms of support load + extra development) for us as an app vendor.
Really hope that Android 8+ incentive manufactures to just use the standard Android mechanisms: they seems to work quite well in my experience. You can run things in the background, but only if it has a user interaction as a result: i.e an alarm notification. The user can then determine if this is wanted or not directly from the notification itself.
Unfortunately it is not much better on the Apple side of things with local push notifications limits.
Interesting edge case! This is why it may be sensible to do some extra checks in things like product expiration batch jobs, to check if the previous run was not to far in the future or past and refuse to run in that case.
Scary to think what might happen if some database purge process is running after this bit flip!
Interesting UI; I really like the way you can rearrange things visually in way that makes sense to the user.
Was able to get a simple flow up and running quite fast. There are a few rough edges though, had a small issue with the URL field of the http integration.
I'm currently working on a similar (hopefully more simple and cheaper) product MetricBoard (direct demo: https://metricboard.io/webui/demo)
Although this currently only let's you push metrics via the API or upload a CSV. I personally would not be comfortable having a 3th party connecting directly to my database.
The product is still in development but I would love to get some first feedback / user testing.
What is cool: you can also see the 3D image without any aids; just by crossing your eyes while looking at the 2 images. This way you can see the tracking in action.
Their appears a 3th image in the middle which you need to focus on and on both sides a non-depth "ghost" image.
Takes a bit of practice! (Not sure if this is damaging to your eye sight; try at your own risk)
I wonder: is EC2 secure enough for this type of credit card store? What if the management layer running the underlying hosts is vulnerable or a XEN zero-day vulnerability shows up?
I'm sure Amazon does a lot on securing its infrastructure, but for credit card data wouldn't a physical, fenced off server be more secure?
Big fan of BorgBase (the other product by the same company), I have been using them for quite some time for different projects.