Long time ago I wanted to make a small contribution to Stellarium. I have a telescope and "surface brightness" is a much better metric than what it showed at the time. I downloaded the code and with a quick inspection found out how to implement it. I modified the code and prepared a patch. When I was going to send it, I discovered someone else had simply implemented it a few days earlier. Nice. It saved me a little work.
Now, what impressed me: I didn't explore it much but it gave me a very good impression of the code. I could find what I needed to change and someone else, without talking to me about it had the exact same idea. The changes were EXACTLY the same. I can only think this code is extremely high quality. It seems to be a standard developers should aim for.
I think this is the sort of thing that developers really want, when they consider introducing a Domain Specific Language into their project: to take changes that, for either language-level or project-architecture reasons, currently have to be made, painfully, across N different parts of the code, ensuring they're all coherent with one-another and that none are missed; and to replace that with such changes requiring that only one piece of code be changed, where that code communicates the central spirit of the business constraint, from which all of the changes to disparate concerns in different modules, can then be derived.
But, of course, even more ideally, you can 1. choose a language and 2. architect your project in such a way, that you don't even need any DSLs in order to accomplish that. :)
"A good set of data structures, interfaces, and functions" is great at the design stage. It's also great for implementing an elegant reference implementation (i.e. one that is meant more for documentation than use — one that you'd describe in a journal paper to communicate the algorithms and data structures involved, for example.)
But I bring up choice of (programming) language as an issue, because in many languages, once you need to operationalize your codebase — make it efficient and scalable, optimizing it with respect to real use in the field, then you'll begin to need things like:
• static data in user-defined complex data structures (incl. ones like graphs with cycles) burned into the program at compile time
• memoization / dynamic programming caches to accelerate costly computations of otherwise-pure functions, esp. for computations done to instances of data structures but where the memoization only helps if done globally across all data structures
• ADTs that are actually implemented in terms of multiple different underlying data structures depending on the properties of the data itself; where, upon mutation of the data, the implementation — and thus the representation of the data — can be swapped out transparently (think: lists in CPython; or Integers vs BigIntegers in Ruby; or most data structures in Redis with their "ziplist" variants)
...and so forth; then often the language will start actively fighting you, as the language has been designed to do everything at runtime; and especially has no consideration for mixing compile-time, runtime-memoized, and runtime-pure sourced data using the same set of algorithms. So you have to write two or three different implementations of the same code, and store your static data in special ways, and mess up your ADTs with indirections, and your data structure constructors with heuristics, and define global caches where much of your data actually lives, turning your concrete modules inside out and making it very hard to reason about them... and so on.
This all gets fixed if you define a DSL. You're basically turning all of the above operationalized logic, into just an opaque "platform" runtime. But you still do have to maintain that "platform."
But some programming languages are already essentially such an operationalized "platform" runtime! Though, such languages are almost always only operationalized for specific use-cases. They're not quite domain-specific languages (insofar as a domain is a vertical); but they are always extremely "opinionated" languages.
I think it also is a measure for technical debt. If someone can easily understand the code and make changes, it is a sign of low technical debt.
Too often developers measure code quality by applying personal subjective measures, like number of lines per method, DRY or choice of programming language and start making major refactoring based on personal preferences.
If someone without knowledge of the code can swoop in and make meaningful changes, it does not matter how many lines of code there is or if it is built with X or Y. It's the end result that matters.
As a converse view point, in my experience, in terms of huge methods and huge files / classes, its rare to see developers who have the mindset of "in general, I prefer small files and classes, but in this case, it makes sense to have a huge function, so I make an exception."
What I do see every day is "oh yeah, this method / file is pretty big, lets add one more thing to it anyways, I dont have time to refactor", and things grow and grow out of control.
I think one basic, and yet rare ability of a professional software engineer, and the skill that should separate you from a hobby programmer, is writing your code in a way which can scale and grow. The strategy for this cannot just be "let me put everything in one file, class, method and lets just see what happens".
That can be an OK first draft approach, but there needs to be a second step. And ultimately, if you set the architectural pattern of "big hairball", everyone else will happily follow it since its not their fault the architecture is like that - they are just adding one more thing. That can be OK for a first draft, but you will have to go back and introduce architecture and modularity at some point, or watch the project collapse under the weight of its own mess.
Once you see enough of those failures, you can start sensing basic patterns for introducing modularity, boundaries and structure to a project, to its modules, and to its classes and methods. As you keep flexing that muscle, in my experience, the "this code is best written as a huge single method" approach basically never seems like a good idea anymore.
Not sure why this post is anonymous. I wish most folks would treat code quality this way!
How hard is it for a developer make this particular change?
And I mean literally observe this up close: navigating the directory structure, reading the docs, typing the code, running the app to check if everything works as expected.
Was it easy? What can change about the code, tests, docs, etc so future changes can be easier?
That's what really matters. Other measures are just proxies to the above analysis.
Honestly, my work place is filled with inexperienced people who have decided what the right approach should be. I'm older and more experienced than most and have learned that I can't win all battles, and bite my tongue when I see them making bad decisions. It's a form of age discrimination where even the management thinks that "young people see problems with fresh eyes". I don't want to come across as an "ok boomer" developer stuck in their old ways. "Rewrite everything in the new untested framework? Sure why not. The code is over 2 years old, so it's full of crusty legacy code".
I may seem a bit bitter in my comments, but I'm mostly disillusioned and are trying to see it as a learning experience. I'll give my opinion sometimes, and if they don't follow it it's not my problem. They will just need to learn the hard way and will probably end up in my situation in a few years.
I'm just collecting my pay check and planning to move on to a work place with more balanced demographics.
Haha right :) Though I feel we're talking of different levels of granularity: I've seen that quote applied at a level close to single operations, which makes sense when you're making judgment on a programming language or API. In OP's case I imagined a somewhat larger piece of code.
i was working on internationalization for a big C++ / QT project and I basically just copied the technique + strategy that Stellarium used. worked great.
Stellarium is also scriptable, so I was able to write a cronjob that would launch Stellaris in an invisible background window, set my latitude and longitude, set a bunch of display options, save an image of the rendered sky to a file, and then update my desktop wallpaper to that file.
The former. A tiling WM covers the entire desktop with whatever windows are visible in the workspace. One window starts out full screen, creating a second window halves the first one and tiles them side-by-side, and so on. I would only see the desktop when I switch to a new empty workspace, but the reason I switched to a new empty workspace in the first place is because I wanted to start a new window there, so that glimpse of the desktop would be short-lived.
Many tiling WMs have an option for gaps between the windows. Do you find them unpleasant? I love my 8px gaps. Most of the wallpaper is still covered, though.
I agree. For me the point of a tiling window manager is that it efficiently uses the screen space automatically. I don't have to drag windows around to do it.
Automatically wasting space sounds less attractive...
Tiling window managers generally size windows as large as possible. Windows only shrink to make way for other windows, so unless you do something weird, or switch to a desktop with no windows, or have some sort of transparency enabled, you won't see your background at all.
Another Software for that is KStars/EKOS. It also does fancy stuff like plate solving and focusing with external focusers. Pretty Powerful, especially in combination with Astroberry
Wow, nice and extensive write up! Share some more photos (if you like) and also write something about focusing (I’m assuming you’re using a Bahtinov mask) and stacking.
If I'm honest I struggled to complete the write up as I wanted to be reasonably detailed about each step of the design and build. I appreciate it could do with a few more photos or illustrations, and I may come back to this in due course.
Really enjoyed reading about your build — I learned quite a bit! I do understand what a slog it can be to write up something with a lot of technical details, so thanks for taking the time! Any suggestions on good resources for learning Fusion 360 with a focus on creating models for 3D printing?
I can't recall what resources I used to improve with Fusion 360; there are a wealth of resources out there, I recall I did watch a few youtube vids on the subject. I'm not a complete stranger to CAD though, I've dabbled here and there for about 20 years or more, once I got a grip on the core workflow of Fusion it came together quite easily, and couple that with playing around with the various tools to see what works. There are times in the modelling flow that you may get a bit stuck due to the order of operations you have applied. Fusion keeps a timeline history of operations and it's somewhat possible to "refactor" it by moving things around - that can both fix things and also make your model break completely. So, I'd recommend looking up best practices for your model and history management. Also, don't expect to get your modelling right first time, or to be able to learn using your main project model, you can easily learn a lot using a bunch of test files to try things out, and apply those techniques to your project afterwards.
With regards to using it for 3d printing - I don't recall again using any specific resources for this, but the main thing was figuring out tolerances and fit for parts. Again, use test models and print small test parts to see what works on your printer. Fusion's parameters can help here, as you can set up variables for tolerances/spacings and update them after the fact.
Agreed, but I'm thinking this could have been done 15 years ago or more? Google Maps let you scroll around in real time way back when. Not correcting, just sort of asking--I'm way behind on how graphics coprocessors work these days.
Maybe you could have used Shockwave or something? But until WebGL implementations were shipped in 2011, there was no 3D API accessible from Javascript. At the time, Google Maps just did 2D tile scrolling. I remember being super impressed when it started letting you zoom out to the globe like you could do in Google Earth.
You should try writing some code to pixel-shade a screen-sized canvas in JS (which you'd have to do to get the textured skybox). I don't think the performance would be usable, especially 15+ years ago.
You simply chop up the textured skybox into tiles and then draw them using transform and drawImage. This was supported beginning in 2008.
Sure it wouldn't be as perfectly accurate as a custom shader for rendering accurately rendering each pixel of a spherical skybox, but it would certainly be good enough.
Stellarium is wonderful. My favourite feature is the ability to change sky culture. The Japanese one is so strange and poetic. A single band of small constellations that crosses the sky like a vertical line of Kanji and includes constellations with names like 'emptiness'.
That whole region of the sky is quite impressive, because along with Andromeda chained to the rock, there is Cetus, the sea-monster, approaching to devour her; Perseus, the hero, flying to her rescue; Pegasus, the winged horse upon which Perseus is flying; Cepheus, Andromeda's father; and Cassiopeia, Andromeda's mother, whose actions set the whole story in motion.
I used Stellarium to generate the realistic (but somewhat over exaggerated clarity) skies for my web game. The day/night cycle only shows stars at :50-00 of each hour: earth.suncapped.com.
I'll edit into this comment a link to the texture files if I can, but the game uses compressed (ktx I think) textures since the star textures are large resolution, one of the largest game assets!
I picked a particular date, time, and place on earth for rendering the sky in Stellarium. It also had options for seeing (clarity) and which features to show, such as planets or space debris.
Thank you. Right now it's a just explorable small section of Colorado. The premise is a post-earth world where players build up villages around trade, inspired by Ultima Online.
I wrote a few scripts to help people study the orbits of the first five planets and moons with Stellarium. Here's one that is supposed to simulate a TV station that is on an hourly loop (it uses your computer clock to decide what should be showing at any minute of the hour)
It's one of the few things left in too-bright places that can introduce someone to the wonders of space in a way images and video can't. Some neighbors finally stopped and asked why I stood at the road looking at the mostly starless sky most nights.
"Waiting for the space station." (and other satellites, but those are harder to see)
"I didn't know it was still a thing."
It started as a little dot on the horizon, barely visible in the hazy light from the city, then built to a blinding light above. I heard a "holy fuck" so I guess they were suitably wowed.
You can go a step further: get them into ham radio and talk to the astronauts as they fly over. Then when/if that gets boring, move on to SSTV and SDR.
It's such a shame Iridium flares are no longer a thing. The ISS is in the sky a bit too long really. I've showed people and they thought it was a plane (despite telling them a planes lights would flash). A good Iridium flare was unmistakable though and quite the arresting sight.
The last one I be tried to look for would have been perfect. It was supposed to happen on a friend's wedding night. It happened but was thoroughly unimpressive. I found out soon after the satellites were in the process of being decommissioned and flares were no longer happening as predicted. By now they're all gone and we just get boring objects like the Starlink satellites.
Its worth mentioning that nobody is doing anybody a favor by using their free software. It seems pretty plain that the free version is a trial you are expected to uninstall or upgrade.
I use Sky Guide on my phone and it's still one of these apps that make "modern" technology feel amazing, similarly to just being able to point Flight Radar at the sky and see where a plane is going.
I do too, its alot of fun identifying random satellites, plus the paid version is an easy way to financially support the desktop. And the developers are actually responsive, which is refreshing.
all satellites viewed with the naked eye look like a "glowing dot". in long exposure images, they look like long single pixel streaks which makes them easily different than a meteor which flares wider in the middle before narrowing again as well as also changing colors.
The Celestia project was dormant for nearly a decade. It becomes hard to package unmaintained software. I haven’t kept up with who the new owner is or what they’re doing, so there could be reasons it hasn’t been picked up again by the distros.
Back in the late 2000s, Celestia was certainly an amazing experience for me. I see there’s a mobile version now, which makes me happy. It works pretty well on my iPhone, although the UX is not perfect.
Does anyone have any resources for projecting stellarium onto the ceiling/walls of a room to mimic the sky above/around? I dug into it a bit and it seemed like projecting into a boxy surface could be accounted for easily enough. But I couldn't find a projector for a decent cost that wasn't too bright. Would be a really fun diy project for me, if I could figure out the hardware.
It’s not stellarium, but I’ve got a DarkSkys DS1 and bought my parents a FX model and they both have far higher fidelity in the image displayed due to using chrome disks instead of a screen. It looks better than anything I’ve ever seen at home.
I cant find the link, but I i recently saw a projector project where someone used a deconstructed android phone with the backlight removed from the screen, and a light/lens combo to get >1080p. Though that limits you to Android apps or RDP, it might be a starting point to hack your own.
Stellarium does have an android app but its a fraction of the desktop app functionally.
Thank you for this. I just installed it an it was exactly what I looked for when I bought my Oculus: the opportunity to explore, zoom and learn about the night sky freely in 3d. I tried many others but this has been the only one to fill my expectations.
I remember going to a planetarium at the local university while in school some 15 years ago. They told us how they use Stellarium to create the skies and Celestia (https://celestiaproject.space/) to create scripted tours for their exhibits. Both were compatible with the hemispherical projector they used.
As soon as I went home I downloaded them both and spent hours visiting stars in Celestia and exploring the sky in Stellarium. It’s great to see they are still quite active.
I love Stellarium. It got me into stargazing. I didn't realise at first that you can play with time, speeding it up, or go to specific times in the past or future to watch certain events like transits.
There was another free software program that I thought of as a companion to Stellarium that let you fly through space. It used logarithmic scales for everything to make it manageable and really gave you an idea of the vastness of space. But I can't remember the name of it nor has searching brought it up.
I'm hoping somebody here knows what I'm talking about.
Is there a text-based version of such a thing? Say I give that lat/long and date/time; I want to know the positions of the planets and some of the major stars.
I've been using XEphem 4.1 on Win11 using WSLg and it works well. But I noticed a Windows installation is available of Stellarium -- I'll give it a try.
I have never managed to get the atmospheric model to reflect what was visible at more than one zoom level. I think it's because they increase your light gathering power as you zoom in, as if you were switching to a bigger telescope to improve your aperture limitation, while in reality you usually zoom by changing lenses that keep the lowest visible magnitude the same.
I use the mobile version regularly, especially when it's warmer outside than it is now, and TIL that it is open source. Now I consider purchasing the pro version, as a form of donation.
The pro version is a bit pricey, for an open source app and for something most people will only use on occasion. Also an app like this doesn't do much so I wonder why limit it by locking-away some features.
SkySafari is a better app for actually doing astronomy, but the pro version is quite expensive, and each major version is a new app that you have to pay for again if you want to upgrade. I bought it a few versions ago and still use it regularly.
well yes, but it likely will be a “telephone number” and not even a simple one like say `2MASS J19593766+2246141` which is 2MASS (the survey name) and the coordinates of the star in the J2000 epoch: 19:59:37.66 +22:46:14.1 .
The Gaia ones (which is the billion star catalogue) look like `Gaia DR3 1827256624493300096`; the number basically contains the rough coordinates of the star as a HEALPix index (along with some other data) so it's not really human readable, but is perhaps more suited for a survey with billions of sources.
Ironically, the Gaia catalogue is incomplete at the brighter end (very bright stars like Betelgeuse for example are not in the catalogue at all) so still needs to be supplemented by other catalogues (and can't be used as a single source of truth to which all other catalogues are cross-matched for example)
I imagine some OSS authors don't consider someone visiting the GitHub readme before visiting their website. I can't fathom thinking like that, but it must have never crossed their mind.
The project website is at http://stellarium.org/. There is no need to have images inside a project repository. Every maintainer already knows what it looks like. What next? Marketing materials?
I disagree. Users, not just maintainers, discover projects through GitHub. In this context, the README effectively serves as a secondary project landing page. IMO, for a visual project like this, images, or a direct link to images, is a must.
Then a link to an example image on the web site is much better.
The idea is to help people understand the project. Not to give them an investigation task. I don’t know the structure of that web site or if there are even images there.
The first time in your life that you learn that a project's code lives on GitHub and its documentation and marketing website are someplace else, you'll start looking for the website reference in the GitHub README or searching for it as a matter of course. It's really not that big a deal.
What’s more amazing to me is that for open source projects like this where anyone can contribute, people would rather complain about the lack of a screenshot instead of submitting a pull request adding a screenshot to the README.
You could probably become a very prolific contributor just by adding a screenshot to every such repo you come across.
If it requires little effort, it's fine, but generally before working on something one should ask the maintainers whether the status quo is deliberate.
This is my primary experience with READMEs as well. I feel like this is one of those new users not appreciating the history and morphing into something they understand with zero interest in the old ways
I followed that link and didn’t see any images there.
I could also google “stellarium project images” but I think my point is that I would expect projects to be as explicit as possible about “this is what we make.”
I don’t know! I wasn’t aware this sort of thing existed, and am interested now that I know it exists, and the main link took me to the GitHub readme, where I can get very little signal on whether it’s worth clicking around and doing more research.
It seems to be an unpopular opinion, but I do think an easily accessible, compelling narrative on the entry pages to a project are good for telling a story and getting engagement from the outside world.
Now, what impressed me: I didn't explore it much but it gave me a very good impression of the code. I could find what I needed to change and someone else, without talking to me about it had the exact same idea. The changes were EXACTLY the same. I can only think this code is extremely high quality. It seems to be a standard developers should aim for.