creichenbach

I know at least 5 Pharo users, and one of them wrote a book about it (for the other 4 :P). They were part of a research group at university and made us students use it. I get why it's nice and all, but honestly it feels a bit like Crossfit, or Vim. There are a small handful of excited users who try to convice everyone else how amazing it is. (Sorry, Oscar et al.)

Those three colored shapes at the bottom look a lot like the EPA logo, a former grocery store chain: https://de.wikipedia.org/wiki/EPA_%28Warenhaus%29?wprov=sfla...

https://billhillapps.com/ Mostly from the time I was actively building and maintaining mobile apps. It's slightly outdated, but I'm still proud of the metro-style design.

> it added additional delays to the entire system

Yes, obviously. And that hurts statistics. That's like killing sick cattle to be able to say that 100% of yours are healthy.

As per my other comment, Swiss trains (especially SBB) are not as pleasant as they get credit for. I get a lot that "you know, in other countries it's much worse", and it reminds me of software hosting, where it was normal in the past to be offline occasionally. Then Google et al. came and showed that much more reliability is possible with good engineering. I think there would be a lot of room for improvement.

I'm a heavy public transport user in Switzerland, and even though it's almost a meme how reliable the trains are, reality is different. Yes, they operate in a way that make the stats look good (x% on time), but they take tradeoff to get there. E.g. they won't await connections if another train is a few minutes late. So you might have to wait for 30 minutes for the next one, or even longer if you're unlucky. And there's the occasional big incident, where you get stuck for several hours. I missed flights that way, even though planning in 3 hours of buffer. There is zero compensation in such cases as long as they bring you to your destination on the same day. Plus, several trains are regularly way too crowded.

Banks have stupid rules probably made by people who don't understand the matter. A relative recently got victim to phishing and gave away some of his banking details (fake e-banking login screen on a website). After locking the account, the bank said it would only unlock it after the phone got wiped, which obviously doesn't add anything in this situation.

Another pet peeve is that they prevent screenshots simply because they can, and it feels safer. I know, 3rd-party apps which can do screenshots etc., but this is fighting the threat the wrong way. And yes, it's partially the fault of the platform, which could just allow user-initiated screenshots. Or at least make it configurable.

I've done it before on a personal project and I was pretty obsessed with user experience. For example, I changed the way buttons work (because they were natively links with Cordova, which trigger upon tap, not "finger lift", like native buttons). Also, implemented some gestures to e.g. switch between pages (tab-style navigation). While not really in line with system UI (wasn't my goal), I think usability is quite decent.

In case you're interested, the app is named "QuickÖV" - not relevant to anyone outside Switzerland, but just for trying it out: https://play.google.com/store/apps/details?id=com.billhillap...

That's still a bit risky as Arizona might just change its time zone definition on a whim. I'm an engineer on one of the big calendaring applications, and it's mind-boggling how often stuff like this happens world-wide, sometimes short-notice (a few weeks in advance). It regularly gives us headaches.

Neat. I built something similar but web-based for Java years ago: https://scg.unibe.ch/wiki/projects/DoodleDebug

Well, among other things. Native APIs are another thing that comes to mind, but those can be bridged more easily I suppose.

Well, to have a perfect-ish solution, you'd have to build a framework with UI elements that map to native elements on each platform. Behavior and styling (e.g. positioning of elements) would need to be consistent, so you'd probably have to reduce functionality to the least common denominator for each possible dimension, or take the burden of implementing compatibility for A on platforms B and C. Web has a legacy of document-based components, while mobile is generally more interactive. There are overlaps nowadays, but staying within those boundaries would be a serious restriction.

On top of all that, you'd need a runtime that works on all platforms and is able to interact with native controls. I think React Native does something like that, but back then when I checked they did not have official web platform support (which is somewhat ironic, but I suspect technical difficulties too).

A few years back I looked around what options exist for building a cross-plattform app. It should support mobile platforms (at least Android and iOS) as well as the web, properly.

The problem with cross-platform frameworks is that they either focus on a good mobile experience, and web becomes an afterthought, or vice versa, meaning mobile basically embeds a browser. Flutter is one of former; back then the web variant was in alpha and basically just a canvas that couldn't even adjust aspect ratio. Since web had priority for our project (accessability, reactive scaling, etc.), this was a no-go.

We ended up going with Ionic (which is basically Cordova with some components on top). The web experience is tweakable to a low level, and the mobile experience is acceptably good, even if not perfect. And we get to cover 3 platforms with the effort of building for ~1.2 apps (there is some platform-specific work involved still).

I'm not even sure if cross-platform is at all solvable in a perfect way, since the UI patterns between mobile and web are just too different.

Years ago I built the same kind of app for Windows Phone 8. I can't find any reference online anymore, though I still have the git repo.

It was motivated by my girlfriend stating that it's hard to understand one's size in the various systems that are in parallel use, at least in parts of Europe. Worst part is that some systems have weird overlaps where not only they use the same "alphabet", but also the homonymous sizes partially cover the same range, but don't match exactly. Therefore it's impossible to exactly convert between sizes, and they should be derived from raw measurements.

Meta: This website has one of the worst and most ridiculous cookie opt-out mechanisms. You are expected to read through a wall of text and follow complex instructions to manually opt-out of each vendor.

Sometimes I have a song stuck in my head when I wake up in the morning, so I started tracking it. There's no text, just a music video occasionally. Not sure if it's interesting to anyone else though. https://morningtunes.music.blog/

I think the numbers in reality are a bit worse. I recently lost my wallet, noticed about a minute later and went back - it was already gone. Later someone found it in a trash can, emptied of all money. This happened in Switzerland, which is at the top of this list, and I've heard similar stories before.

I wonder how/where the author gets connection time information. Each country, and sometimes each public transport company, seems to have their own system, sometimes hard to access digitally.

I've been building a mobile app for quick and convenient public transport departure lookup in Switzerland[0], which is doable because there's a free, well-documented public API[1]. Since it's fairly popular, I thought about extending it to other countries, but as mentioned above, the API landscape looks super heterogenous and spotty.

[0]: http://billhillapps.com/billhill/quickov.html [1]: http://transport.opendata.ch/

A couple years back at university, I created DoodleDebug[1,2], tackling some of your mentioned issues. It can be thought of as a graphical version of System.out.println(). There is a similar output format customization mechanism as toString(), but you can also customize the rendering of arbitrary types you don't control the source code of.

DoodleDebug's output is HTML-based and interactive with semantic zoom. That means you can click parts of printed objects to inspect them.

However, I didn't work on it in years due to lack of time, and even the linked description page is a bit outdated (it's not an Eclipse plugin anymore).

[1]: http://scg.unibe.ch/wiki/projects/DoodleDebug [2]: https://github.com/CedricReichenbach/DoodleDebug

Edit: Maybe this PDF of my Bachelor's thesis gives a better overview of what DD is and does: http://scg.unibe.ch/archive/projects/Reic13a.pdf

I recently introduced proper minification and tree-shaking to my Cordova app and noticed it only reduced size by ~23% (after 2+ years of active development, so quite some code).

Looking at the output directory, I saw that the fonts I'm using make up about 45% of the whole app!

Selecting a list of airports, or an area, or city with distance range would be nice. From where I live, there are multiple airports about the same distance away, and I don't care much which one I use; but it might make a huge difference due to different airlines.

Ah, that's actually not too far idea-wise from what we ended up doing: https://news.ycombinator.com/item?id=16637525

Ah, so your first suggestion would be basically building an auto-encoder based on training data with correct and incorrect words (fragments). This might work, but it would require a lot of computation: Each word of the vocabulary multiplied by all its similar counterparts. And this wouldn't cover new/unknown terms yet.

What we ended up doing for now is a two-dimensional input layer with per-column one-hot encoding of characters (i.e. one character is one column, 128 rows for the ascii alphabet). Then, apply a convolution with kernel dimensions 3x128, which flattens data to one dimesion and combines three neighboring characters. The second part builds an "assiciation" between neighbors, which helps yielding similar outputs for similar word fragments.

This works quite well, except for some nasty limitations:

- Search queries have a hard limit in length, caused by our input layer dimensions

- Due to varying search query length, input nodes on the right side are often unused/zero, leading an weighting bias on the left side when training. That is, the start of search queries receives more attention that the end. But that's not necessarily a bad thing.

That sounds interesting, do you happen to have a documentation link or similar? I can't seem to find any info about it.