whouweling

Very interesting concept and clear messaging on the website. Eager to test this for personal use.

Big fan of BorgBase (the other product by the same company), I have been using them for quite some time for different projects.

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.

Interesting, will certainly try it out, thanks!

> 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)

Very interesting, question: from the pricing page: it is unclear to me what is meant by phrases in the context "100 Phrases" for $99 plan?

Could also be the difference between searching with a clear goal in mind and discovering of new ideas & interests?

This looks really nice, clean & functional. I'm integrating this into my personal website at this moment. Thanks!

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?

As others replied; it does. But the API does not behave consistent on different brands and API levels.

Also some manufacturers cancel alarms when the user swipes away an app (which some users do constantly to keep the recent apps list "clean")

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.

Will try it out for more complex scenario's ...