This update focuses on minor UI improvements, compatibility with older versions of macOS, and adds some clarifying warning messages to the app. This version is available for and compatible with OS X 10.7 Lion through macOS 10.14 Mojave, continuing my commitment to making sure the app works with as many versions of macOS as possible.
Addresses an issue which could cause the Daily Usage window to display a dark-mode background on macOS 10.13 High Sierra and earlier
Added a new warning on the Daily Usage window to warn when the user is not using a compatible connection and the app cannot retrieve usage details
Made some minor tweaks to improve compatibility across all versions of macOS
This update adds compatibility with macOS Mojave’s Dark Mode and focuses on minor usability improvements, as well as fixing an issue that caused an informational message to be inadvertently displayed numerous times on the daily usage window (in some cases). The app now knows you don’t need the same information 3+ times.
Sorry for the delay in getting this update out (just over 2 weeks after macOS Mojave was released. It should have been earlier, and I know better from now on 😀). This update required some refactoring in order to support Dark Mode and be more context-aware for future macOS enhancements that are inevitably going to arrive. Some more details about the UI enhancements in Start Usage Meter 2.5:
About Dark Mode macOS Mojave introduces Dark Mode for the Mac, which provides a darker appearance for UI items. Start Usage Meter 2.5 introduces support for Dark Mode across the app (including the daily usage window). There’s nothing you need to do, since Start Usage Meter will detect whether Dark Mode is enabled, and automatically show the darker interface.
About the usability improvement
As mentioned, this update includes usability improvements. This primarily surrounds the ability to identify which connection you currently have selected at a quick glance, without leaving the window you’re on. For example, the Usage Details window now displays the currently selected network on the titlebar of the window. You no longer need to click the submenu on the macOS menu bar and scroll through the list to identify your currently selected network.
It seems like a small change; however, this makes sure that the app gives you all the information you need at a quick glance, without needing to tediously click through menus to get the critical information you need.
OS Support Details Keeping up with my goal of making sure Start Usage Meter supports all versions of macOS (ahem. OS X) going back to OS X 10.7 Lion, Start Usage Meter 2.5 also supports all versions of Mac OS X back to OS X Lion. As long as nothing forces me to increase my deployment target (i.e. Xcode requires all new builds with a new API to target OS X 10.8 or higher), I will continue to build in legacy support in the app as long as it doesn’t hinder the experience on newer versions of macOS. As always, the latest version of macOS runs Start Usage Meter the best.
An update has been pushed out to ActorAgeCheck.com. This update made some changes to the core foundation of the website and its backend in preparations for a big overhaul that I first mentioned in the last website update.
Since the last update, I’ve made progress on all the items I had previously mentioned, including the full deprecation of the old image subdomain.
Todays update consists primarily of backend overhauls in preparation for a completely redesigned and vastly improved version of the site. These changes are mostly on the backend; however, since the current iteration of the website is able to utilize the new backend, there are some changes on the frontend (as the backend does a lot of content generation). As a result, the current website (1.0.34) is utilizing some components from the new backend, which results in a slight change to how some content is presented on the current site.
Some temporary changes as I prepare to launch the new site:
TV Shows are referenced in some places on the site. It is pulling these references from the new backend; however, the functionality is not yet complete and the current frontend cannot interface with the new responses from the backend to actually display any TV Show content. The ability to search TV Shows and display their information will become available when the new website launches, and won’t be available prior to that.
Some API’s are returning slightly different responses with modified organization. This is temporary while the old frontend still exists. Once the website is completely overhauled, the responses will return to the original organization.
Some API’s have become exposed but are not used on the current frontend. For example: search autocomplete. The frontend has exposed a new script that returns autocomplete results for the search field. It is in development and testing and is not currently active. Like the TV Show functionality, this feature will become available when the new website launches. You should not be calling it from your scripts, since its state is likely to change prior to launch.
This update to Speech Jammer focuses on stability and usability improvements rather than introducing new features. It includes some fixes to recording sharing, some improvements to the initial starting delay, improvements to AirPods compatibility, and updates core SDK’s that the app relies on.
Fixes an issue that could cause the upload to fail (but appear to succeed) when sharing a recording. Recordings of any size should now share properly once again!
Reduced the default/initial delay time to help have a larger impact and crank up the fun 100% (that number was arbitrarily made up, but I’ll bet it is somewhat accurate)
Improvements to AirPods compatibility and improves compatibility with other Bluetooth headphones. More enhancements coming soon!
Updated core SDK’s to improve reliability, stability, and performance
This update was set as a phased release and will release to users in phases over 1 week. You can force the update by opening the App Store and manually updating Speech Jammer.
An update has been pushed out to ActorAgeCheck.com. While I am planning an overhaul of the entire website, I’ve gone ahead and released a maintenance update to improve the performance and reliability of data on the website. Additionally, this maintenance update includes various server-side enhancements that will carry over into the new overhauled website. I’ll post more on the brand new overhauled version shortly.
This maintenance update (1.0.33) includes:
HTTPS is now enabled and forced on all domains. Non-HTTPS links will push users to the equivalent HTTPS page.
Images are now served by the image subdomain by default on mostpages. Some pages may occasionally revert to the old https://actoragecheck.com/image/ URL. This will eventually be completely phased out in favour of the image subdomain which boasts a much faster response time since the image no longer passes through a few servers for processing.
Deprecation heads up: The https://actoragecheck.com/image/xxx.png URL that still serves images is being phased out and will eventually (prior to the overhaul) no longer serve any images. If you link or reference images, please prepare to move to the new https://image.actoragecheck.com/ domain which is far more responsive.
Caching is now utilized for almost all lookups to improve the responsiveness of movie and actor detail pages. These lookups are now aggregated and cached on the ActorAgeCheck server and will be served if the cached data has not expired.
CloudFlare has now been applied to all aspects of the website as another layer of caching and to improve content delivery
Movie and actor lookups are now limited to 20 results each to improve performance
The FAQ section is being moved to a separate link rather than an HTML object with a :hover CSS rule. This will improve the sites usability. * Note: this change may take a couple of weeks to roll out to all visitors *
Thanks for your support! The overhauled website will be detailed shortly, but this maintenance update will enhance the experience on the current website. It focuses primarily on responsiveness, caching improvements, and forcing security. All of these changes are also laying the foundation for the new site.
Please note, due to the aggressive intelligent use of caching, some of these changes may not be present on all pages of the website. As cached data expires server-side, the new data pull will contain any relevant changes as mentioned above. Since cached data is still valid, I’m not going to flush any of the currently existing cache, but will instead roll features in and phase deprecated functions out as I can. This will make sure the site remains reliable and responsive.
As previously discussed, this update addresses a few minor issues that affected users on versions of OS X older than macOS 10.12. The app has been slightly overhauled to improve compatibility with OS X versions dating back to OS X 10.7 Lion. The only feature limited to OS X 10.8 Mountain Lion and later is notifications (since OS X Lion does not have a notification API).
Please note that the best experience with Start Usage Meter is always on the latest version of macOS, although I do my best to support as far back as I can. I have no immediate plans to discontinue support for OS X Lion users, since I know there are still users with machines that cannot progress past it. As long as I still have the tools (i.e. Xcode doesn’t impose a minimum target greater than OS X 10.7), I will continue to target OS X Lion and later.
I appreciate your patience while I repaired the issues aforementioned. I have a few exciting enhancements planned for future updates and will preview them shortly. Even if you’re on a newer version of macOS, you should still update to Start Usage Meter 2.4.4.
Some changes were required since the deployment of a brand new Start.ca website (that looks fantastic!) which was incompatible with previous versions of Start Usage Meter. Most of the issues were corrected with a server-side adjustment, but there are some client fixes required.
Addresses several issues that were introduced due to the last update to the Start.ca website including:
Fixed an issue that caused usage data to fail to load after the latest Start.ca website update which could cause an error to display indefinitely
Fixed an issue that prevented a users usage key from being populated automatically after the latest Start.ca website update
Improved the crash resistance throughout the app to prevent future changes like this from causing the app to crash
Completely revamped daily usage window to address crashing and prevent future changes from causing the app to terminate
This update also has the benefit of increasing performance and reliability in the daily usage window, so I’m going to go ahead and take credit for that too.
Although the website has since been slightly modified to address some of the issues users on Start Usage Meter were experiencing and usage will now display properly on 2.4.2 and earlier, there will still be some crashing issues on the daily usage window that requires 2.4.3 to be fixed.
Additionally, there is a known issue on OS X Lion that is causing the date selector on the daily usage window to stop functioning. This has already been addressed in the latest 2.4.4 beta and will be released to the App Store sometime next month. This issue is due to a missing API on OS X Lion and does not affect OS X El Capitan or later. 2.4.4 will bring a fix for users on older operating systems.
As always, thanks for continuing to support the usage meter. I love seeing the emails of happy users.
As I continue to move forward (at least I’m hoping this is forward), I notice that there are a lot of people that just don’t seem to see the value in a vacation. Ever since I was young, my family and I have taken yearly vacations to the Caribbean. Although as a kid, it was just really cool to go to a tropical destination for a little while and take a break from this cold harsh weather we have in Canada.
However, now that I am a little older, I see that it means so much more to me now. It is no longer just a break from the weather, but rather a break from reality as a whole. The vacation gives something that is planted and firmly placed in time to look forward to. It is the light at the end of the tunnel when work starts piling up. It’s a chance to throw all worries away and get away from everything. I realize the importance of a vacation now more than ever before. You have to enjoy life, and part of that (for me anyway) is putting your hands in the air and leaving your desk behind for a week with no thoughts about what you were just doing.
A vacation is vital in a successful career. It sparks passion and gives you a chance to think about potential ideas without being required to think about them for lucrative reasons. I generally head back home with a new smile and a new chance to build something truly spectacular that I enjoy. Moreso, it renews my excitement for what I do.
Maybe it’s just me… maybe it’s a sign that what I am doing needs to change more frequently so I don’t fall back into that rut. However, it seems like a getaway every year ensures that my passion for what I’m doing is renewed.
If you’re ever feeling dull or like you’re stuck in the same-old same-old routine, hop on that next plane to a sunny destination. I suggest Royal Caribbean! Sail away!
The best part of my profession is that we can create whatever our heart desires. If it doesn’t exist, we can bring it into existence.
Our home is protected/monitored by both cameras (motion activated) and a central station. This camera notifies us via email whenever motion is detected along with data from the motion. This system works fantastically, but we came across a bit of a nuisance factor. Whenever we bring in the groceries or do something that involves walking in front of the camera multiple times, we’re left with dozens upon dozens of notifications.
My solution: to only activate the camera when our homes security system is turned on. There is no feature to do this out of the box, so I had to get creative. The best part of programming is the ability to logically figure things out and create functionality where none exists.
I did this by getting my monitoring company to notify my server whenever the system is armed or disarmed (securely), and send some information. The server takes this information in, analyzes the situation (for example: are we gone or home, are we secured?) and stores the knowledge in a secure file. Whenever the camera detects motion, instead of emailing us, it now sends the email to my server. The server grabs the email content with images/data and checks the status of the alarm. If it is armed, the motion is probably of interest to us and it is sent on its way. Otherwise, the server throws out the message and just places a log of the data in a file for later viewing if necessary.
This is an unofficial method to a problem that both companies have not solved (which is fully understood, since they’re unrelated). They both simply had some tools that I found a use for. One of the best parts of being an artist/programmer is the ability to solve problems where other people may go “someone should do that.”
I finally went through and updated my entire site to Retina-ready images. It was a bit of a bigger effort than I had thought (even though there aren’t many resources that needed to be upgraded).
Icon is from Analog, a really cool app. Check it out!
The decision to make my website Retina-ready came from me browsing other sites over the past little while and realizing how much better websites that were Retina-optimized looked on my laptop. It had a massive impact on my opinion of the company/person who owned the website. For example, a software company was much more likely to get my purchase if they had a Retina based website. When going back to check in on my site (a whole re-write is in progress as well, hopefully launching within the next month or two)– I had noticed that my website looked dreadful on Retina displays (and decent on non-retina displays).
I decided to re-write my pages to use divs for images instead of tags. This allowed me to make use of WebKits new CSS4 image-set rule (-webkit-image-set). This makes it easy to serve up non-Retina images to non-Retina displays, and Retina images to Retina displays without wasting bandwidth. My previous Retina implementation involved sending pixel-doubled images to all users (@2x). This resulted in more bandwidth used, and scaling down being done on non-Retina displays which made the image look awful. I now have two versions of every image on this site. One at regular resolution, and one @2x the resolution.My whole website is now Retina optimized with all images using div’s and the -webkit-image-set property. This means that the Retina imagery is only available on Safari/Chrome/other WebKit based browsers at this time. Other browsers do not currently support the image-set implementation. Therefore, if you’re using a browser other than a WebKit based browser, you’ll be served a non-Retina image regardless of your display.The other benefit of this approach is that it will render and update dynamically based on the screen you’re using. For example, an external monitor that’s not Retina will show the lower resolution image. However, if you drag at least 50% of the browser over to a Retina display on the same machine– the browser will load the high resolution images without reloading the page.
Where am I taking this? I plan to make all future websites, and updates to this site– Retina ready. It really makes me look better as a developer, and allows me to be happy when looking at my own site. I also plan to bring these changes over to some freelance websites I’ve done, including Innisfil Dental’s website.
What? Retina?! What the heck is that? And why do you need to optimize? A “Retina” screen is a screen where the human eye cannot discern pixels at a normal viewing distance. Retina displays run at double the resolution, or 4 pixels per CSS pixel. This means that if a website is serving a 300×300 picture, a Retina display is actually rendering that image at 600×600, scaling up. This would result in a seemingly blurry picture on these ones since WebKit needs to guess the additional pixels it’s missing. Websites should detect the screen pixel multiplier, and serve the appropriate image (300×300 to non-Retina screens, and 600×600 to Retina screens).
I am still experimenting with this, but please contact me if you have any input.