Didn't even get a reply... it cost me quite some hours to do this in a language I have almost no experience in.
At least there was the upside that I got to experience Clojure and Om which was great to learn about :D
Granted, my assignment was smaller and I knew they would get back to me. If I had been asked to develop a spreadsheet editor from first principles that would have been a major red flag.
- Will feedback be provided on the submitted application?
- What does that feedback look like, are you spending 60 minutes asking about my implementation choices or will you also spend time offering feedback on how I could have improved my solution?
For any hiring managers by providing feedback to candidates you are showing that candidates will grow and develop on your team. By not providing feedback you risk ending up like Roam Research and loosing out on many potential applicants because you demonstrate that you aren't interested in developing your staff.
Didn't even get a reply...
Don't feel bad, you're not the only one they didn't bother replying to:
Unless your complaint was just about the lack of follow through, that's valid, kind of shitty to not be told that you didn't get the job at least.
Anyways, my point is, interviewing just sucks.
Taylor Holliday of the Audulus fame is porting it to Rust
There is at least one important feature that is missing that many desktop apps need so I can't unreservedly recommend it for that yet, but for mobile development it is very nice. I am much more productive with SwiftUI than anything else.
Compose at least makes it only a library bump away.
> Compose at least makes it only a library bump away.
this to me is the most annoying thing with regard to swiftui and apple development in general... especially considering swiftui views are mostly wrapping uiviews....What would you say are the core concepts that make it click for you? Do you have any resources to recommend?
Such as: when exactly should the other side update? When the user switches focus (where to?) or on every keystroke? Does it make sense to a user that they temporarily see the Fahrenheit value for 2°C if they really want to type in 20°C? What happens if they type an invalid value (or clear the box, which they often have to do)? What happens if they type an incorrect value and then type something into the other field? Etc etc.
I think there are a lot of interesting tensions between a "formally correct" system and one that feels usable and intuitive to use. Especially with bidirectional data flow, they show up quickly.
I think most of your 'when should the fields update' type of questions, have already been solved in Google Translate web UI. There, you can only update the left-sided input field. So there becomes this simple flow of: 1) decide which language you're translated from. 2) edit that value. 3) the UI picks up that a keystroke has not occurred in the last X seconds 4). The right-hand side field updates.
As soon as you start asking these questions, the UI requirements change.
So now when the user enters 72°F, it shows 22°C. However, in a naive implementation, updating the celsius field would trigger a change in the other direction as 22°C converted back would round to 71°F. But 71°F rounds to 21°C, triggering another change, etc etc.
The user must drag the slider to find the temperature they have, and read the converted version. May be the slider is marked with different axis top and bottom (may be top is Celsius and bottom is Fahrenheit).
The temperature converter is a good example of an “implies” relationship, which Sean argues is difficult to model in UIs.
Or even 2 completely separate pages, 1 for C and 1 for F.
A couple weeks ago there was a burst of posts on HN about prolog, a language family I know nothing about. Took no time to spin up dr racket, find a prolog dialect in it, and play around.
I probably do something like that with it every couple months. And yeah being able to easily visually output stuff from a new language without having to grapple with the tooling and output quirks of a new language takes so much of the initial friction out.
See https://github.com/Bogdanp/racket-gui-easy/tree/master/examp...
},
{
title: "Racket",
technologies: ["Racket", "racket/gui"],
link: "https://github.com/mfelleisen/7GUI/",
src: "https://github.com/mfelleisen/7GUI",
},
{
title: "GUI-Easy declarative GUI",
technologies: ["GUI-Easy", "Racket", "racket/gui"],
author: "Bogdan Popa",
authorLink: "https://github.com/Bogdanp/",
link: "https://github.com/Bogdanp/racket-gui-easy/tree/master/examples",
src: "https://github.com/Bogdanp/racket-gui-easy/tree/master/examples",
}
]What if there are circular dependencies?
You could model the dependencies as a directed graph, and ensure that there's no cycles in the graph, and if there is, don't evaluate and warn/error msg the user.
I feel like a Master/Detail task would be a nice addition, and it could include a resizable divider so that the GUI framework's layout functionality is exercised.
Note they’re explicitly encouraging the use of something like JTable/NSTableView in the cells example, the focus is on appearance/behavior customization and change propagation. And in the circles example, undo/redo is ideally provided for “free” by the environment, and with the system’s drawing frameworks & dialogs it really does make for a simple task.
If the environment lacks these basic capabilities though..
And that's the point, right? You're evaluating the toolkit, and if it lacks the features to make these tasks fairly easy, then it's going to be harder to do a lot of straightforward things.
I imagine a similar set of tasks could (and have) easily be contrived for other common libraries/toolkits that are used, such as HTTP client libraries, numerical libraries, etc.
Then again, every language has its strengths and weaknesses so perhaps such projects do not exist?
It's also embarrassingly parallelizable if your language supports parallelization primitives you want to exercise.
For example:
You're loading or submitting content asnychronously and must handle different loading states in order to give the user feedback. If an action fails due to spotty internet you must also include a retry or refresh button.
You load a model form to modify some data, and when you submit your changes someone else has already made modifications to the model.
In this identified case, the gui has to react/behave correctly according to the results/errors of asynchronous remote logic over a spotty network.
They can be viewed with the online editor. For example, the cells: https://slint-ui.com/releases/0.2.2/editor/?load_url=https:/... The cells example is actually not finished and admittedly missing a lot of features, it is far from being a spreadsheet.
Show HN: 7GUIs in Vanilla HTML, CSS, JavaScript - https://news.ycombinator.com/item?id=28600804 - Sept 2021 (56 comments)
7GUIs - https://news.ycombinator.com/item?id=24958725 - Nov 2020 (56 comments)
7GUIs: A GUI Programming Benchmark (2018) - https://news.ycombinator.com/item?id=21883306 - Dec 2019 (16 comments)
7GUIs – A Notational Usability Benchmark for GUI Programming - https://news.ycombinator.com/item?id=15703230 - Nov 2017 (6 comments)
7GUIs – A Notational Usability Benchmark for GUI Programming - https://news.ycombinator.com/item?id=9050480 - Feb 2015 (17 comments including "Very cool to see my master's project here on hn")
Now I’m totally going to run off this list. I've only got circles and cells left before I can do all of these challenges.
1 - Make your resume into a slide show with background music.
2 - Create fancy transitions
3 - replace the numbers in your slideshow resume with fast running counters that count up to the desired value.
4 - add something original that you feel should be part of the task
5 - create a fully functional inquiry form as the final slide of your resume
6 - All tasks are optional, have the amount of work you put in reflect how desperately you need this job.
The website hasn’t been rebuilt but you can see the list of implementations here: https://github.com/7guis/7guis/blob/master/site/src/containe...
So a second version of this challenge might be to implement the same capability, through a more native interaction idiom. Suspect much can be learned by doing it both ways.
Using these as template starting points is a great idea.
this is like the Todo applications for GUI