If you're talking about thumbnails, I think they made the right choice. Just the top part of the homepage already contains 5MB of image assets. Scrolling down a few times quickly ups that to 15MB and more. I'd rather have reasonably sized and optimized images throughout the site - with high resolutions ones as downloads - and a very speedy browsing experience, then the other way around.
However, I would expect the online tiled image viewer to show the full, high quality image - at least, when zoomed in.
It's a nice exercise, but please be aware that using that font in your website makes it terribly hard to read for users who need to zoom in. As in, enlarged pixelated letters are even harder to read then blurry ones. Bitmap fonts are only good on exactly the original size they're designed at.
In my experience, margin isn't harmful. Using a container to space components relative to each other is harmful.
In fact, using margin correctly can prevent an explosion of exceptions on the relative positioning of your components. It also brings you more in line with how a designer thinks.
Consider this: one of the things a designer takes into consideration is composition and whitespace. In effect, this means that distances between components might change, depending on what their layout is, and what components are situated around it.
When you have a wrapper component, you can set some sensible spacing defaults for its children. But some components visually need more breathing room, while others need less. This depends on the design of the component. It also depends on what components comes before or after, so a simple padding won't suffice. Two visually heavy components need more space in between as compared to two that are visually airy. You'll eventually end up with a long list of + selectors to precisely tune every single combination. This quickly gets out of hand. With or without a wrapper element, those exceptions must be applied somewhere.
However, when using margins, you avoid all that. Since margins collapse, you can be assured that any combination of components has the minimum amount of whitespace between them, determined by who needs the most. Now this isn't perfect, but it gets pretty close; any component that needs a bit more breathing room can force a larger distance. This way, you might still have one or two combination exceptions, but these will be rare.
So, looking at it like this, margins _are_ a property of the component itself: it's the equivalent of a guy stretching his arms out and saying "don't come too close, I need my space!".
The style of question marks used, while perhaps correct, is extremely uncommon in Dutch. It's also not easy to type, even with a Dutch keyboard layout. I'd bet that the author is German.
I've been a developer in both good and bad Scrums. Usually, the difference boils down to one or more of these points:
- Is the product owner any good? (physically present, has mandate, shields the members from company politics, open to story input from the team; like taking care of some tech debt or swapping stories around to fit developer needs, setting requirements that are not too rigid)
- Are the team members any good? (physically present, self-sufficient, experienced enough or with a buddy, communicate open and clearly with the product owner and other team members / disciplines, flexible enough to produce a balanced result within the requirements)
- Is the scrum master any good? (physically present, proactively alert for difficulties in the process or team, encourages interdisciplinary pragmatic solutions, expectation management product owner, balances the needs of the team vs the needs of the product owner, enforces 5 minute standups in the morning and a good but short retrospective after a demo)
- Is the project any good? (realistic budget and MVP, enough room for creativity in development and design, good reason for existence, stakeholders that show up for demo's and stay for the drinks after)
- Is the location any good? (a reasonably creative environment, preferably where stakeholders cannot make surprise visits, with an open floorplan so interdisciplinary communication is encouraged, with all needed materials and enough room on the walls for a scrum board, a burndown chart and to drown them in things like post-its, designs and technical schematics)
- Is the timing any good? (one to two sprints minimum to get the team oiled, not more then 3 days a week - so the other 2 can be spent at a lower tempo, no team members with large attendance gaps or shuffling people in and out, not more then 12-16 sprints because if the project needs more then clean it up, have some downtime, and start a phase 2)
I probably forgot something, but I believe these are the main issues that can really influence the success (and pleasure within) a scrum. One or two issues can be worked around; any more and the project is a drag or even a bust.
No, it does't allow comments. Fortunately, a project README has more then enough room for any remarks. Yes, you're better off putting numbers in strings. No big deal.
But also:
JSON files are easily readable by default, in a lot of
languages. Knowledge about (the limitations of) JSON can easily be assumed. Alternatives like YAML, TOML or any of the others all have their own idiosincracies.
And non-programmability is a good thing. It might be more verbose, but you don't have to fire up a javascript environment or bash interpreter or some such just to read a configuration file. And separate code paths are very explicit since that will mean separate objects or even files.
I would like to try to switch to a JetBrains IDE. Especially the refactoring tools look to be much more advanced then Atom or VSCode.
At my workplace, most developers are either full stack or backend (python). As such, we have a grab bag of PyCharm licenses. However, I am purely a frontend developer, so frontend related tools are much more important to me then python support.
Unfortunately, the last time I tried PyCharm the integration with linters, toolchains, different template languages etc. was quite limited. Or perhaps I couldn't find the needed extensions or where or how to configure the right settings. I don't know if this is a JetBrains IDE thing, or simply because PyCharm is so geared towards Python development only.
The projects I work on are integrated in different backend systems. So one might be a C# project with Razor templates. Or it'll be some PHP with another templating language. Or it might just be mustache or handlebars. It might be a SPA in Angular, Vue or React. It might be purely Node.JS project. Some projects have Webpack, some have a Gulp toolchain. Linters might differ between projects. Folder structure also differs, one might have the git repository in the root. Another will have it one or two levels down. Some use a python virtualenv. Others use a docker container. Others use no enviroment management at all.
In my experience, because of the different nature of the projects, the PyCharm editor offered little extra functionality over Atom/VSCode, while missing a lot of simple extensions that Atom/VSCode does have. I was also quite a bit slower to start up.
Is it possible to configure / extend PyCharm to offer the same frontend related functionalities as WebStorm, or is a separate license needed? And is there support, or are there extensions, to support different toolchains, linters, templating languages etc. per project? The backend language support can be limited, as long as the very basics are there, and I'd like advanced frontend support for refactoring, debugging, etc.
I've always thought that "visualizing" something is a metaphor for "think about it" or "list the properties you know".
This explains so much, at least for me.
How I always skip the long visual descriptions in books since they add nothing to the story; there is no visual component to reading a book. Why meditation is nearly impossible unless I manage to think about nothing, which is extremely hard. How I can recognize faces but not describe them, even those close to me, other then a short list of features that stand out.
Or how I can recognize a smell, but I can't tell you what the smell of a hamburger is unless I actually have one in front of me. Why people describe dreams or memories like watching a movie, while it's more a combination of emotions, situation descriptions and something that feels like the echolocation of a bat. What some people mean when they can hear a person speak or have a discussion in their head.
It explains why it's so easy to recall emotions and factual information, but nearly impossible to recall anything else. Why my "now" is so strongly affected - emotions experienced in the current moment tend to influence the vague feelings of the past, as if it's always been that way. Why it's always been so difficult to work towards certain goals, unless they're divided up into sub goals that are so close as to be easily attainable. Anything further in the future is nearly incomprehensible. Why it's so easy for me to navigate through bad experiences, but not for others, because beyond needing to process the emotions, the rest will fade away like all other experiences.
Some of those might be because of something unrelated. But somehow, reading this article, has answered a ton of questions I didn't even know I had.
My mind is truly blown.
Though one aspect I don't have: If I think about a song I know well, I can play it in my mind. The experience is almost, but not completely, like hearing the song in reality. So at least there's that. And that also explains why music is so much more "real" then anything else to me.
Can I share some observations? There are a few things I really love about this:
- You kept the end user in mind: You. The GUI looks like a mashup, in a good way: A Mac OS menu bar, Windows GUI feel and a NextSTEP launcher on top of a Unix like system. It shows that for every element, instead of simply recreating whatever system you decided to emulate, you took the parts you liked best from whatever system and simply recreated that. I haven't looked at the code too thoroughly, but I can probably find the same mindset there.
- You kept the scope tight. It's easy to lose sight of the bare minimum MVP, especially when working on a hobby project. The functionality showcased here tells me that whenever you started implementation of a feature, you built exactly what you needed, nothing less, nothing more.
- You also didn't get bogged down with premature optimizations. Yes, the PNG renderer is slow. But it does the bare minimum it's supposed to.
But most of all, this takes a crazy amount of time, skills and dedication. You've probably encountered quite some frustrating moments you had to chew through, but now you're here, presenting your work. And it's awesome!
I think it's interesting how debates about Electron inevitably end up with the arguments 'the developer wants X' vs 'the user wants Y'. However, there's one aspect a lot of people seem to overlook in their arguments: pragmatism.
The ideal application:
- uses almost no memory
- uses almost no disk space
- is extremely fast
- costs (next to) nothing
- and has all the features in the world
- presented in a manner that automatically shows the user only the exact features (s)he cares about
In the real world, we have to balance the project/product requirements. In the end, only these things matter:
- It yields a net profit (monetary or otherwise) for the company or owner
- It has (and keeps) added value in comparison to similar software
- It's fun to design and develop in/for
- It has bugfixes and new features in a timely manner, without taking up too much development time
- It has a pretty, easy to use interface
- It's quick and snappy enough to run
Adding that all up, and developing in something like Electron is a no-brainer: mean time between iterations is faster, design and development is more fun and the end user has a product that is fast enough for their needs packed with features. Try that in any low level language or without control over the engine and you'll have to severely hamper one of these goals.
However, I would expect the online tiled image viewer to show the full, high quality image - at least, when zoomed in.