SkyTools 3 is done. Both editions were completed last week.
It's a bizarre experience. There I am working toward something that has taken four or five years to accomplish, depending on how you count it. As the final months come the days-off get fewer and fewer. As the final weeks come the days-off disappear completely and the work days grow longer. Constant coding turns into creating artwork for the packaging. The last few days become a blur. Code that was prepared months ago that is only used in the final product is at last integrated. The bugs continue to flow in from the test team and must be squashed immediately, even if it means a late night. Plans that were made years ago are put into motion. The website must be updated. Difficult but critical questions have to be answered, such as, "How many of each edition should I have made?" And above all there is that constant, ever present question: "Did I forget something?"
It all builds to that that final day when the final CD master is burned, somehow always only ten minutes before the UPS overnight pickup deadline. The package is sealed and raced to the drop. And then its over.
It will be two weeks of waiting before the packages are returned and we can start shipping.
People keep asking me, "Is it done yet?" and I just stare at them, dumbstruck. Saturday morning comes and I feel guilty for not getting up early to go to work. My desk is a mess. I guess I should clean it off now. The "to do" lists that ran pages every day now only run a page for the week. It is peaceful. Serene. But that constant, ever present question remains: "Did I forget something?"
It's like a Shuttle launch but sort of backward. There is a slow ramp up of thrust that builds to the great deafening explosion of launch, followed immediately by an equally deafening quiet and a feeling of weightlessness... of drifting.
And of course, "Did I forget something?"
Sunday, December 7, 2008
Wednesday, August 20, 2008
Asteroid Excess
We're about ready to start the final testing of the "Pro" version of SkyTools. There are just a few loose ends left to tie up, such as the new serial number code, enhancing the installer, etc.
Oh, and all those pesky asteroids.
When I first wrote the asteroid code for SkyTools there were between 8000 and 9000 known. By the time SkyTools 2 came out there were so many that I only put the first 10,000 numbered asteroids on the CD because there wasn't enough room for them all. Today there are nearly 200,000! That's so many that drawing asteroids on a chart is really bogging down.
Here's how the asteroids that are shipped with SkyTools work: asteroids use osculating elements, which are a sort of cheat. These elements would describe the orbit of the asteroid perfectly if there were no other bodies in the solar system. But with all those other asteroids and planets out there the reality is that each asteroid gets tugged around over time, changing its orbit. So the orbits we use are sort of freshness dated. They are good for about 40 days. What I do is run whats called an "n-body" program that carefully computes the position of each asteroid over many years, including all the tugging. Every 40 days a new set of orbital elements are generated. When you ask for the position of an asteroid SkyTools finds the set of elements closest to your time and uses it to compute the position.
The supplemental asteroids, which are downloaded over the web, work in much the same way. Each new set of elements you download gets added to the database. Over time you will build up a database that covers months and even years.
This all works pretty well, except for how long it can take to run through the nearly 200,000 asteroids sorting out the ones bright enough and within the bounds of your chart. Fortunately I had an idea come to me in the middle of the night a few months ago. It's one of those ideas that I would really like to claim is perfectly brilliant, yet it's so obvious I probably really ought to be ashamed I hadn't thought of it before.
The idea is to store a set of positions and magnitudes along with the orbital elements for each asteroid. Since the elements are only used for a known 40-day period we can compute a list of positions over that period (using the elements). When we want the position we interpolate to get a good idea of the position and magnitude of the asteroid. Only if the asteroid is on the chart do we go ahead and compute the accurate position. Interpolation is cheap so the end result is that the asteroids plot a lot faster. How much faster, I'm not quite sure yet. But I expect it to speed things up a lot.
Unfortunately there is a downside. The positions stored with the elements have to be pre-computed. I just tried downloading and pre-computing all the known asteroids and it took a whopping 8 minutes on my aging computer. In fact, that's why I'm writing this. I'm running another test and it's a long wait...
Fortunately I have some ideas for speeding it up!
P.S. I tested the new asteroid code and it is 12x faster!
Oh, and all those pesky asteroids.
When I first wrote the asteroid code for SkyTools there were between 8000 and 9000 known. By the time SkyTools 2 came out there were so many that I only put the first 10,000 numbered asteroids on the CD because there wasn't enough room for them all. Today there are nearly 200,000! That's so many that drawing asteroids on a chart is really bogging down.
Here's how the asteroids that are shipped with SkyTools work: asteroids use osculating elements, which are a sort of cheat. These elements would describe the orbit of the asteroid perfectly if there were no other bodies in the solar system. But with all those other asteroids and planets out there the reality is that each asteroid gets tugged around over time, changing its orbit. So the orbits we use are sort of freshness dated. They are good for about 40 days. What I do is run whats called an "n-body" program that carefully computes the position of each asteroid over many years, including all the tugging. Every 40 days a new set of orbital elements are generated. When you ask for the position of an asteroid SkyTools finds the set of elements closest to your time and uses it to compute the position.
The supplemental asteroids, which are downloaded over the web, work in much the same way. Each new set of elements you download gets added to the database. Over time you will build up a database that covers months and even years.
This all works pretty well, except for how long it can take to run through the nearly 200,000 asteroids sorting out the ones bright enough and within the bounds of your chart. Fortunately I had an idea come to me in the middle of the night a few months ago. It's one of those ideas that I would really like to claim is perfectly brilliant, yet it's so obvious I probably really ought to be ashamed I hadn't thought of it before.
The idea is to store a set of positions and magnitudes along with the orbital elements for each asteroid. Since the elements are only used for a known 40-day period we can compute a list of positions over that period (using the elements). When we want the position we interpolate to get a good idea of the position and magnitude of the asteroid. Only if the asteroid is on the chart do we go ahead and compute the accurate position. Interpolation is cheap so the end result is that the asteroids plot a lot faster. How much faster, I'm not quite sure yet. But I expect it to speed things up a lot.
Unfortunately there is a downside. The positions stored with the elements have to be pre-computed. I just tried downloading and pre-computing all the known asteroids and it took a whopping 8 minutes on my aging computer. In fact, that's why I'm writing this. I'm running another test and it's a long wait...
Fortunately I have some ideas for speeding it up!
P.S. I tested the new asteroid code and it is 12x faster!
Friday, June 6, 2008
Imagining Imaging
I have some great news. But first some background.
Years ago I had a simple idea: extend what SkyTools does for the planning of visual observations to planning imaging sessions. It seemed trivial because the two kinds of planning are so similar. After all, it's still about observing an object high in a dark sky. It seemed that all it would take would be a few tweaks to make the planner more imaging friendly.
In designing the planner for visual observing my approach was to come up with the basic questions that an observer might want answers to, such as, "Can I see this object in my telescope from my backyard tonight?" Or, "Which of these objects in my list should I observe tonight?" And, "When is the best time to observe this object tonight?"
To answer these questions I borrowed, enhanced, and even developed from scratch science-based models for atmospheric extinction, the brightness of the sky, and the visibility of objects in the telescope. In SkyTools 3 these models are now very sophisticated. To make these models work you must teach SkyTools about your telescope, your observing location, and a even a little about yourself. Many people don't realize it, but the ability of SkyTools to compute the optimum time to observe an object is the critical component. I leverage this ability in every way I can think of to create the various visual observing tools. This optimum time computation, along with the quality of observation assessment that makes it work, are the engines that makes SkyTools go.
For imaging support I turned to the very same process: create a list of questions to answer, develop a science-based imaging model, and allow the user to tell SkyTools about their imaging system. I did most of the model last summer and I was pleased with the results. But a nagging question remained: what was the analogue to the optimum times for visual observing that would serve as the engine for planning imaging sessions? And not only that, but in the end would I be able to offer something more than what is already available? Is there a useful niche for SkyTools to fill in the imaging world? These questions have nagged me for over a year now. I knew that at the heart of deep sky imaging is signal to noise ratio (SNR), but how to leverage it? Visual observing is about a brief moment in time, but imaging is about an exposure that can last many minutes or even hours. And unlike visual observing the brightness of the sky is not always critical. So the questions become, "Should I bother to image this object from my light polluted back yard or wait until I can get to a dark site?" Or, "Is it worth imaging when the moon is up?" These questions simplify to, "If I do image in a bright sky, how many more exposures will I need to get the same result?" And, "Is there enough time to make it worthwhile?"
To be honest with you, even as recently as a few weeks ago I didn't know how to best answers these questions. I had most of the pieces in place for planning imaging sessions, but it had yet to come together. Programming for me is a lot like digging a tunnel through a mountain, where you start at each end and hope to meet in the middle. I've been told that a "good" software developer (or team) sits down and designs the entire project in advance. But I have found, at least for me, that in practice this is usually only a good start. Not only do problems emerge that you had not anticipated, but the very act of writing the code often brings new insights. So as I build the code both from the bottom up and from the top down I try to remain as flexible as possible. The process that unfolds feels like a journey. I'm never really certain how it's all going to work out. Where will we meet in the middle? Will the result be useful? In many ways I feel like I'm just along for the ride, following along where the code takes me. Thankfully this creative process has seldom failed me. (Unlike my predictions for how long things will take!)
I am pleased to announce that my ride is almost done. Things have come together. Important questions now have answers, and I look over what I have created and I am excited by the result. The feeling of satisfaction derived from taking an idea from a mere formless seed to fruition is wonderful. This is what it's all about for me!
We should begin beta testing the Pro version (with imaging support) in a few weeks. I am very excited about sharing it with everyone and equally excited about working with the team to put a nice polish on it.
Years ago I had a simple idea: extend what SkyTools does for the planning of visual observations to planning imaging sessions. It seemed trivial because the two kinds of planning are so similar. After all, it's still about observing an object high in a dark sky. It seemed that all it would take would be a few tweaks to make the planner more imaging friendly.
In designing the planner for visual observing my approach was to come up with the basic questions that an observer might want answers to, such as, "Can I see this object in my telescope from my backyard tonight?" Or, "Which of these objects in my list should I observe tonight?" And, "When is the best time to observe this object tonight?"
To answer these questions I borrowed, enhanced, and even developed from scratch science-based models for atmospheric extinction, the brightness of the sky, and the visibility of objects in the telescope. In SkyTools 3 these models are now very sophisticated. To make these models work you must teach SkyTools about your telescope, your observing location, and a even a little about yourself. Many people don't realize it, but the ability of SkyTools to compute the optimum time to observe an object is the critical component. I leverage this ability in every way I can think of to create the various visual observing tools. This optimum time computation, along with the quality of observation assessment that makes it work, are the engines that makes SkyTools go.
For imaging support I turned to the very same process: create a list of questions to answer, develop a science-based imaging model, and allow the user to tell SkyTools about their imaging system. I did most of the model last summer and I was pleased with the results. But a nagging question remained: what was the analogue to the optimum times for visual observing that would serve as the engine for planning imaging sessions? And not only that, but in the end would I be able to offer something more than what is already available? Is there a useful niche for SkyTools to fill in the imaging world? These questions have nagged me for over a year now. I knew that at the heart of deep sky imaging is signal to noise ratio (SNR), but how to leverage it? Visual observing is about a brief moment in time, but imaging is about an exposure that can last many minutes or even hours. And unlike visual observing the brightness of the sky is not always critical. So the questions become, "Should I bother to image this object from my light polluted back yard or wait until I can get to a dark site?" Or, "Is it worth imaging when the moon is up?" These questions simplify to, "If I do image in a bright sky, how many more exposures will I need to get the same result?" And, "Is there enough time to make it worthwhile?"
To be honest with you, even as recently as a few weeks ago I didn't know how to best answers these questions. I had most of the pieces in place for planning imaging sessions, but it had yet to come together. Programming for me is a lot like digging a tunnel through a mountain, where you start at each end and hope to meet in the middle. I've been told that a "good" software developer (or team) sits down and designs the entire project in advance. But I have found, at least for me, that in practice this is usually only a good start. Not only do problems emerge that you had not anticipated, but the very act of writing the code often brings new insights. So as I build the code both from the bottom up and from the top down I try to remain as flexible as possible. The process that unfolds feels like a journey. I'm never really certain how it's all going to work out. Where will we meet in the middle? Will the result be useful? In many ways I feel like I'm just along for the ride, following along where the code takes me. Thankfully this creative process has seldom failed me. (Unlike my predictions for how long things will take!)
I am pleased to announce that my ride is almost done. Things have come together. Important questions now have answers, and I look over what I have created and I am excited by the result. The feeling of satisfaction derived from taking an idea from a mere formless seed to fruition is wonderful. This is what it's all about for me!
We should begin beta testing the Pro version (with imaging support) in a few weeks. I am very excited about sharing it with everyone and equally excited about working with the team to put a nice polish on it.
Monday, April 14, 2008
Real (long) Time
It's Monday, I have a headache and I don't feel much like working, so I thought I'd finally post something on my blog. Usually what happens is if I think about writing something I decide that working on the program is a better use of my time. That's why you haven't heard from me much in the last few months.
Before I get to the fun stuff, let me say that "it" has happened again. At every point in the process of developing SkyTools 3 I have run into the very same problem, and even I, head deeply buried in the sand, am beginning to see a trend. I have been operating under a very basic misconception. I know this may sound ludicrous to some of you but I naively thought that SkyTools 3 would be easier than SkyTools 2. My reasoning went something like this: ignoring the database updates, which I know is always an enormous job, most of the actual programming was already in place. To add a new feature or extend functionality would be simple. But that is not the case. Instead, as the program becomes ever larger and more complex, just about anything I do to it becomes more difficult, requiring ever more time and testing. It has become rather clear that the methods I had used up to now, which had served me well, are no longer viable. I have begun to rethink everything with one goal: to release an upgrade every two years. Wish me luck.
Looking at the calendar I can see it is already April and I haven't got the Pro version testing up and running yet. The main reason is that, once again, I have greatly underestimated how much there was to be done. Not to mention all the distractions, like spending several hectic days and late nights last week moving my web site to a more reliable host. And even the testing is proceeding much more slowly than our original Real Time testing did. For instance, I released a bunch of new Real Time features last Friday with the expectation that at least some testers would try them out over the weekend. But so far I have heard nothing. I don't know if it's weather, if the testers have lost interest, or what. Regardless, it is a bit disheartening. I'll have to move on. And when bug reports finally do come in I'll have to go back and figure out what I did, where the code is, remind myself how it all works, and in the process leave what I have started in the meantime half finished. Then I'll have a similar problem when I go back to what I was working on.
But as always, there is a pretty big pot for at the end of this rainbow for SkyTools users. My knack for overreaching means that there are many new features, several of which were unplanned. Here are some of the highlights:
Offset Tracking: telescopes that support this capability can be set to follow slow moving objects. This can be done by entering the R.A. and Dec. rates manually, or by letting SkyTools to it automatically; just target a Comet or Asteroid and the telescope should automatically track its motion. I can't wait to hear from someone how it actually works in the field!
Mount Alignment tool: I have developed a simple, but I think very useful, tool to align your telescope mount via the drift alignment method. SkyTools will pick an appropriate star for you, target your telescope if connected, and display a finder chart. The best part is that the eyepiece view of the chart splits the sky into north and south zones that are labeled by the direction in which you should move your mount. It takes all the guess work and confusion out of the process. I am really happy with it, but again, I'm anxiously awaiting to hear what the testers think.
Native Argo Navis support: in addition to directly supporting the Argo Navis in Pushto mode now you can download SkyTools observing lists to the unit for use in the field. Comet and asteroid orbital elements are automatically uploaded and you will be able to give each list of objects its own identification to help organize your observing.
I have also added support for Pier flipping and selecting basic tracking rates.
Finally, in the process of making charts for finding the exact location of each pole for polar alignment, I realized that SkyTools was somewhat deficient when it came to targeting the poles. So I added a new "object" classification called Reference Points, which includes the Celestial Poles, Galactic poles, galactic center and Zenith. These reference points can be chart targets, added to observing lists, and appear labeled on the charts.
As you can clearly see, I got carried away again.
Before I get to the fun stuff, let me say that "it" has happened again. At every point in the process of developing SkyTools 3 I have run into the very same problem, and even I, head deeply buried in the sand, am beginning to see a trend. I have been operating under a very basic misconception. I know this may sound ludicrous to some of you but I naively thought that SkyTools 3 would be easier than SkyTools 2. My reasoning went something like this: ignoring the database updates, which I know is always an enormous job, most of the actual programming was already in place. To add a new feature or extend functionality would be simple. But that is not the case. Instead, as the program becomes ever larger and more complex, just about anything I do to it becomes more difficult, requiring ever more time and testing. It has become rather clear that the methods I had used up to now, which had served me well, are no longer viable. I have begun to rethink everything with one goal: to release an upgrade every two years. Wish me luck.
Looking at the calendar I can see it is already April and I haven't got the Pro version testing up and running yet. The main reason is that, once again, I have greatly underestimated how much there was to be done. Not to mention all the distractions, like spending several hectic days and late nights last week moving my web site to a more reliable host. And even the testing is proceeding much more slowly than our original Real Time testing did. For instance, I released a bunch of new Real Time features last Friday with the expectation that at least some testers would try them out over the weekend. But so far I have heard nothing. I don't know if it's weather, if the testers have lost interest, or what. Regardless, it is a bit disheartening. I'll have to move on. And when bug reports finally do come in I'll have to go back and figure out what I did, where the code is, remind myself how it all works, and in the process leave what I have started in the meantime half finished. Then I'll have a similar problem when I go back to what I was working on.
But as always, there is a pretty big pot for at the end of this rainbow for SkyTools users. My knack for overreaching means that there are many new features, several of which were unplanned. Here are some of the highlights:
Offset Tracking: telescopes that support this capability can be set to follow slow moving objects. This can be done by entering the R.A. and Dec. rates manually, or by letting SkyTools to it automatically; just target a Comet or Asteroid and the telescope should automatically track its motion. I can't wait to hear from someone how it actually works in the field!
Mount Alignment tool: I have developed a simple, but I think very useful, tool to align your telescope mount via the drift alignment method. SkyTools will pick an appropriate star for you, target your telescope if connected, and display a finder chart. The best part is that the eyepiece view of the chart splits the sky into north and south zones that are labeled by the direction in which you should move your mount. It takes all the guess work and confusion out of the process. I am really happy with it, but again, I'm anxiously awaiting to hear what the testers think.
Native Argo Navis support: in addition to directly supporting the Argo Navis in Pushto mode now you can download SkyTools observing lists to the unit for use in the field. Comet and asteroid orbital elements are automatically uploaded and you will be able to give each list of objects its own identification to help organize your observing.
I have also added support for Pier flipping and selecting basic tracking rates.
Finally, in the process of making charts for finding the exact location of each pole for polar alignment, I realized that SkyTools was somewhat deficient when it came to targeting the poles. So I added a new "object" classification called Reference Points, which includes the Celestial Poles, Galactic poles, galactic center and Zenith. These reference points can be chart targets, added to observing lists, and appear labeled on the charts.
As you can clearly see, I got carried away again.
Thursday, February 7, 2008
Time to Get Real
I am pleased to report that the standard edition test/development is finally winding down. There are still some loose ends (there always are) but the vast majority of the program is now in its final state. Man, it's been a really long haul!
The next step is to begin the Real Time testing. I nearly have all the new SkyTools 3 features integrated into the Real Time tab. In the next day or two I'll release it to the team for basic testing, which I have every reason to expect will go quickly. Then the fun begins! I've sketched out the new mounts and ASCOM features that I want to extend Real Time to support. Primarily that will involve adding support for the Argo Navis, Servo Cat, and various push-to devices based on the Tangent chip. Working in tandem with a test team is essential for this next step since I don't have access to any of these devices. Nevertheless, based on previous experience with Real Time, for once I'm confident that this won't take more than a few weeks.
The next step is to begin the Real Time testing. I nearly have all the new SkyTools 3 features integrated into the Real Time tab. In the next day or two I'll release it to the team for basic testing, which I have every reason to expect will go quickly. Then the fun begins! I've sketched out the new mounts and ASCOM features that I want to extend Real Time to support. Primarily that will involve adding support for the Argo Navis, Servo Cat, and various push-to devices based on the Tangent chip. Working in tandem with a test team is essential for this next step since I don't have access to any of these devices. Nevertheless, based on previous experience with Real Time, for once I'm confident that this won't take more than a few weeks.
Tuesday, December 18, 2007
Meet the Nightly Observing List Generator
The new Nightly Observing List Generator finally exists outside of my imagination and has had it's tires kicked around by the test team. It is exhilarating and a bit scary to bring a new feature to life, particularly when I've been thinking about it for a long time. There's just no telling how it's going to work out ahead of time. It's sort of like having children. You do your best and see what happens as they take on a life of their own.
Sometimes things go badly. It may turn out that all the pieces aren't yet in place to really make it work, or that some unexpected development has left the whole idea lame and unworkable. Sometimes I just can't make it all come together to my satisfaction.
But most of the time a new idea soars. I try my best to let it do that, allowing for major changes and redesigns right up to the last minute. Having a sound design going in is very important, but I've found that the best tools evolve in ways that I can't imagine ahead of time. I see it as my job to let them do so. I simply try to hang on for the ride and when we land see where it all ended up. And here we are...
All-in-all I'm very happy with it and the test team is all thumbs up! Most of the concerns I had going in have been worked around to my satisfaction and there were some pretty cool developments along the way. One of my favorites is in the Shallow Sky auto-generated list. Among other things it looks for any fast-moving minor planets that may be visible that night. Another really cool one is in the Interesting Stars feature. As part of its function it looks for eclipsing variable stars with deep eclipses and only lists those that are predicted to be in eclipse that night. Very cool.
Another thing I really like is the ability to prune the list to a small set of randomly selected objects. I enjoy knowing that every time I create an auto-generated list of NGC/IC objects it will give me a unique set of targets for that night. There are so many galaxies and clusters available in my 18-inch. It's like closing my eyes and putting my finger on the atlas to pick my targets. Who knows what I'll find there. Yet with this tool I can be assured that the object will be a reasonably good target that is appropriate for my telescope.
Perhaps the most useful auto-generated list is the one that spawned the idea in the first place: the Showpieces listing. I've already used it myself when I had to be at a star party with very little time to prepare. Recommended targets included the setting moon, Mars, comet 17P Holmes, several nice double stars, and a good assortment of deep sky objects of various types. Planning doesn't get any easier than that!
Sometimes things go badly. It may turn out that all the pieces aren't yet in place to really make it work, or that some unexpected development has left the whole idea lame and unworkable. Sometimes I just can't make it all come together to my satisfaction.
But most of the time a new idea soars. I try my best to let it do that, allowing for major changes and redesigns right up to the last minute. Having a sound design going in is very important, but I've found that the best tools evolve in ways that I can't imagine ahead of time. I see it as my job to let them do so. I simply try to hang on for the ride and when we land see where it all ended up. And here we are...
All-in-all I'm very happy with it and the test team is all thumbs up! Most of the concerns I had going in have been worked around to my satisfaction and there were some pretty cool developments along the way. One of my favorites is in the Shallow Sky auto-generated list. Among other things it looks for any fast-moving minor planets that may be visible that night. Another really cool one is in the Interesting Stars feature. As part of its function it looks for eclipsing variable stars with deep eclipses and only lists those that are predicted to be in eclipse that night. Very cool.
Another thing I really like is the ability to prune the list to a small set of randomly selected objects. I enjoy knowing that every time I create an auto-generated list of NGC/IC objects it will give me a unique set of targets for that night. There are so many galaxies and clusters available in my 18-inch. It's like closing my eyes and putting my finger on the atlas to pick my targets. Who knows what I'll find there. Yet with this tool I can be assured that the object will be a reasonably good target that is appropriate for my telescope.
Perhaps the most useful auto-generated list is the one that spawned the idea in the first place: the Showpieces listing. I've already used it myself when I had to be at a star party with very little time to prepare. Recommended targets included the setting moon, Mars, comet 17P Holmes, several nice double stars, and a good assortment of deep sky objects of various types. Planning doesn't get any easier than that!
Monday, November 12, 2007
The Last Piece
For some time now we've been testing/developing the new Database Power Search on a tab-by-tab basis. Last week I released the new Comets search tab to the test group, and the week before that it was the new Asteroid search. Together they should provide a very interesting tool for mining the databases. For instance, you can filter by asteroid type, such as "Aten" or "Apollo" or "Damacloid." Classifying asteroids and Trans Neptunian Objects by the orbit type is one of the cooler things I've added under the hood, and it's been fun trying to make the most if it. The comet search will be useful for finding out which comet your Grandma saw in the summer of '32 or to look for comets with similar orbits. But of course paramount is always the intelligent selection of observing targets. To aid with that I have added a new Visual Detectability filter and for double stars there is a new Splittability filter. These filters rely on the models I developed to predict the visibility of an object in the eyepiece, and how difficult it will be to split a given pair. Visual observers can use these filters to find "difficult pairs" or "easy" deep sky objects based on their inputs such as date, location and instrument.At first glance the new DPS looks a lot like the old one, but it soon becomes apparent that it's been supersized. I've tried to make small improvements across the board that together add up to something a lot more powerful.
With the DPS done except for a few bug fixes, over the weekend I took up the last piece of the Standard Edition of ST3. I originally called it the Observing List Generator then decided it was an Observing List Wizard. The thing has been evolving so quickly that naming it was a waste of time. It's been part of the Database Power Search, a separate tool, and as late as last night I was considering an entire new tab on the planner for it!
One way or another by the end of this week it is going to exist outside of my imagination. I think you will all like it. Basically it allows you to quickly create a list of objects to observe on a specific night. The gold standard all along has been that it's 4:00 PM and there's a public star party tonight and you are in charge of having something to show people. "SkyTools, help! I'm in a hurry. Just give me a list!" It does more than that, but this particular application has been the driving force behind the tool. Wish me luck!
Now a word about where we are at: after this last tool is released to the testers I'll still have a lot of loose ends to tie up. There are some bugs that still need fixing and a lot of little things that need smoothing over or to be brought up to par with the rest of the program. So my plan is to call a hiatus for the test group for the month of December. I'll go about getting everything finalized and after the first of the year we will have a real beta test. That should not take long. I will also get the Real Time tool ready and we will start a new test as soon as possible, perhaps even concurrently with the other test. When that's done I want to meet with interested imagers and together we will finalize the imaging features for the Pro Edition. The good news is that SkyTools is like a big pyramid and all this stuff is that little part at the top. So I am hopeful we will see a release early next spring.
Subscribe to:
Comments (Atom)
