No, I don't mean reflection in the case of software objects being crawled over by other software to determine what they are and what they can do. No, I mean my looking back at things... I've been a full-time user of a Mac for... is it four years already? Three? I think it's three. My brother recently bought a Mac Mini and ditched his PC altogether. This was prompted by yet another EPIC FAIL trying to get Vista running. Finally he got sick of the whole Windows thing and snagged the mini after hearing me go on and on about how cool and sexy and easy-to-use they are.
EXCELLENT!
He's been asking me questions along the way... "what's this icon that popped up on my desktop when I downloaded something?" and "how do I create or unzip a zip file" and such. It's pretty cool to see the same learning experience happening that I just went thru' a few years ago. He's pretty much up to speed on things now after only a few days and has transferred his data files onto the mini; music files, pictures, documents, etc.
Also, based on my recommendation, he picked up iWork and has been converting his Excel and Word files over. All going (mostly) smoothly.
It's all pretty cool.
In the mean time, I've found some things about the Maintenance Tracker application's GUI a little clunky and am looking for better alternatives on how to do some things. I'm going to be revamping how to add some of the line-item things; parts, service entries, etc. Just not tickled with the lack of flow that I can't seem to get around.
More to follow.
Friday, February 29, 2008
Monday, February 18, 2008
Bug fix release
This version fixes a bug that crept up in the previous versions that is a really odd one. I should have expected it really; especially considering I don't usually like to rely on implicit type casting.
Problem: model year information was not properly casting to an INT type and was causing all saves to fail. The model year is saved in the data structure as a Number->Int. The application form, of course, passes that value as a string. Early versions did the conversion "automagically", but then stopped working.
How/When noticed: this problem seemed to pop up out of nowhere as this particular bit of code hadn't changed in a while. I think maybe a Mac OS point release, or some underlying library update might have tightened up this type of data conversion. This problem seems to be pretty erratic; I was able to save in my test version when changing the year to certain values. Very odd.
Resolution: I changed the code to do an explicit type cast conversion when writing the model year value back to the underlying data object. Looking back, I should have realized earlier this could be a source of trouble. I loathe implicit type conversions, and tho' this worked for quite a while, I'm smarter than this. I'm chalking it up to overlooking obvious stuff while learning Objective-C.
The new code looks like this:
[self willChangeValueForKey: @"year"];
[self setPrimitiveValue: [NSNumber numberWithInt: value] forKey: @"year"];
[self didChangeValueForKey: @"year"];
The old code used to rely on implicit conversion, such as:
[self willChangeValueForKey: @"year"];
[self setPrimitiveValue: value forKey: @"year"];
[self didChangeValueForKey: @"year"];
Moral of the story: Stick to what I normally do/don't - implicit type conversion is evil. Never[1] use it.
Bug fix link:
http://chornbe.com/mt/debugversions/MTDbg_1_1.dmg
Please note, I *think* this should work fine with existing data files, depending on the debug version in use. Please back up your data files (which typically exist in: /Users/[username]/Documents or where ever you may have "Save to..." your files. If you have problems, please consider zipping up and emailing me your data file so I can convert it to the latest format. Unfortunately, early versions had two or three data file schemas and I was rather lazy about up-conversions and backward compatibility.
[1] - Certain languages always permit (and promote) the use of casting to strings as the normal way of doing this. This is OK, depending on what value you're looking to get from an object. But it typically will never fail.
Thanks and apologies for Macrobe in the help tracking this down.
Problem: model year information was not properly casting to an INT type and was causing all saves to fail. The model year is saved in the data structure as a Number->Int. The application form, of course, passes that value as a string. Early versions did the conversion "automagically", but then stopped working.
How/When noticed: this problem seemed to pop up out of nowhere as this particular bit of code hadn't changed in a while. I think maybe a Mac OS point release, or some underlying library update might have tightened up this type of data conversion. This problem seems to be pretty erratic; I was able to save in my test version when changing the year to certain values. Very odd.
Resolution: I changed the code to do an explicit type cast conversion when writing the model year value back to the underlying data object. Looking back, I should have realized earlier this could be a source of trouble. I loathe implicit type conversions, and tho' this worked for quite a while, I'm smarter than this. I'm chalking it up to overlooking obvious stuff while learning Objective-C.
The new code looks like this:
[self willChangeValueForKey: @"year"];
[self setPrimitiveValue: [NSNumber numberWithInt: value] forKey: @"year"];
[self didChangeValueForKey: @"year"];
The old code used to rely on implicit conversion, such as:
[self willChangeValueForKey: @"year"];
[self setPrimitiveValue: value forKey: @"year"];
[self didChangeValueForKey: @"year"];
Moral of the story: Stick to what I normally do/don't - implicit type conversion is evil. Never[1] use it.
Bug fix link:
http://chornbe.com/mt/debugversions/MTDbg_1_1.dmg
Please note, I *think* this should work fine with existing data files, depending on the debug version in use. Please back up your data files (which typically exist in: /Users/[username]/Documents or where ever you may have "Save to..." your files. If you have problems, please consider zipping up and emailing me your data file so I can convert it to the latest format. Unfortunately, early versions had two or three data file schemas and I was rather lazy about up-conversions and backward compatibility.
[1] - Certain languages always permit (and promote) the use of casting to strings as the normal way of doing this. This is OK, depending on what value you're looking to get from an object. But it typically will never fail.
Thanks and apologies for Macrobe in the help tracking this down.
Monday, January 28, 2008
I'm back, baby!
Yeah, whatever, right?
Well, I'm getting back to it. While digging around in the hard drive the other night, I took some time to re-acquaint myself with the Maintenance Tracker project layout, the interface builder and the data model.
I added some new records to my personal data file and took out some stuff for the old bikes. The new bikes are all setup, all the work and part numbers have been recorded, and I found some stuff in the interface - usage stuff - that bugs me and I'm going to fix it.
So... I'm back on task. The last few months I've been going crazy working on a project at work. That's now at a point where it's in "maintenance" mode and I can add features and fix bugs and not get drowned in it any longer. So that's good. Now I have time (and most of all, desire!!!) to get back to the serious business of learning to code for the Mac.
I was pouring thru' the project, both from a user perspective *and* the developer/designer perspective and I found a bug and fixed it. That's cool because it was a nice chance to dive right in and force it all to come back to me. I hope to avoid future stalls in the development and keep things moving forward. I have to break up my lists into tiny tasks and force myself to only work on one at a time, check it off the list, then walk away until the next day or the next week. I think part of the problem before was that while learning X-Code and Objective-C, I kinda burned myself out a little too quickly. Staying up 'til 2am for 3 weeks in a row has a way of being a problem after a while.
All things in moderation and all that.
Well, I'm getting back to it. While digging around in the hard drive the other night, I took some time to re-acquaint myself with the Maintenance Tracker project layout, the interface builder and the data model.
I added some new records to my personal data file and took out some stuff for the old bikes. The new bikes are all setup, all the work and part numbers have been recorded, and I found some stuff in the interface - usage stuff - that bugs me and I'm going to fix it.
So... I'm back on task. The last few months I've been going crazy working on a project at work. That's now at a point where it's in "maintenance" mode and I can add features and fix bugs and not get drowned in it any longer. So that's good. Now I have time (and most of all, desire!!!) to get back to the serious business of learning to code for the Mac.
I was pouring thru' the project, both from a user perspective *and* the developer/designer perspective and I found a bug and fixed it. That's cool because it was a nice chance to dive right in and force it all to come back to me. I hope to avoid future stalls in the development and keep things moving forward. I have to break up my lists into tiny tasks and force myself to only work on one at a time, check it off the list, then walk away until the next day or the next week. I think part of the problem before was that while learning X-Code and Objective-C, I kinda burned myself out a little too quickly. Staying up 'til 2am for 3 weeks in a row has a way of being a problem after a while.
All things in moderation and all that.
Friday, July 20, 2007
Getting back to it
Just a quick note to let folks know I'm getting ready to dive back into Maintenance Tracker and work on some niggling points that were bugging me. With work and summer and kids and sports and ... well, you get the idea... things have been hectic.
But I'm committed to making Maintenance Tracker complete and implementing all the features I had originally planned on. After that, then I'll be looking to implement some of the features submitted by users and readers here on the 'blog. This is the only place that I'm really using to put a public face on this application, and the only from which I'm taking feedback.
I realized that MT was quickly spiraling out of my original design intent; a simple, quick, easy way to gather maintenance information while I learned some things about development on the Mac. I very much like some of the ideas that have been submitted, but they were never part of a rev-1 design and I realized that part of the tempest in the tea cup of my mind was trying to do all of the "back of my mind" design and analysis necessary to get these features compatible with, and integrated into the current app.
I can't do that and keep frequent and quick releases and manage all the other stuff going on and work and riding and... so I won't.
Baby steps. In my early days in the computer business I worked for one of the last true "Consultants" in the computer business (most "consultants" these days are just coding or sysadmin mercenaries; contractors rather than true consultants), and working for this guy taught me many, many things. Prime among them is stick to your plan. Your plan may suck, it may be small, it may be overly simplified. But stick to it. You can scrap the plan, you can modify the plan or you can make a plan to fully replace the plan; but in every case, stick to your plan. He also suggested I read a book by Hal Rosenbluth entitled "The Customer Comes Second". The general message this book conveys is if you're running a business, run it YOUR way. It very much echoes Tom's sentiment of "stick to your plan". Have a vision. Work towards YOUR goals. Like that. (Interestingly, I later went to work at Rosenbluth International working 2 reports below Hal Rosenbluth. We had lunch a few times, I've been to his house. Interesting guy.)
So, for those of your gracious enough to put the effort and time into helping me bring MT to life and allowing me to test my Frankensteinian creations on your computers, thank you. Your feedback is all being cataloged and some of your suggestions are absolutely, positively being integrated into "the plan". But not in the short term. I know some of you are looking for specific features, and some of those ideas are definitely necessary to make MT "complete". I thank you for those ideas. Please... keep them coming. But also understand, I have to meter how I release the app and build versions and trickle-in new features. Some times they're not just bolt-on ideas; some times I have to go in and refactor core code.
This is what was causing me some frustration. I was looking too far into the future and too far out on the revisions. I was not sticking to my plan. I was getting frustrated and began questioning too many of my own choices. MT 1.0 may end up being a piece of crap that no one uses, but in the end I want it to be release as I had originally envisioned it, and I'll take my lumps and learn from my mistakes. This is, after all, a learning experience for me. Some new ideals in software design, some new coding paradigms, some new ways of how I think about software.
To sum up... thank you. Thank you for the feedback. Thank you for the patience. Thank you for the prodding. Start looking for new release announcements in the near future and start looking for new features to begin creeping in. There may be occasions where several releases don't have any apparent new features. They may simply be core enhancements that don't make it in to menu options or GUI components or full on features. I may simply be laying the ground work for later feature releases. But in all cases, rest assured, I'm getting back to it and things will begin progressing again.
Enjoy.
But I'm committed to making Maintenance Tracker complete and implementing all the features I had originally planned on. After that, then I'll be looking to implement some of the features submitted by users and readers here on the 'blog. This is the only place that I'm really using to put a public face on this application, and the only from which I'm taking feedback.
I realized that MT was quickly spiraling out of my original design intent; a simple, quick, easy way to gather maintenance information while I learned some things about development on the Mac. I very much like some of the ideas that have been submitted, but they were never part of a rev-1 design and I realized that part of the tempest in the tea cup of my mind was trying to do all of the "back of my mind" design and analysis necessary to get these features compatible with, and integrated into the current app.
I can't do that and keep frequent and quick releases and manage all the other stuff going on and work and riding and... so I won't.
Baby steps. In my early days in the computer business I worked for one of the last true "Consultants" in the computer business (most "consultants" these days are just coding or sysadmin mercenaries; contractors rather than true consultants), and working for this guy taught me many, many things. Prime among them is stick to your plan. Your plan may suck, it may be small, it may be overly simplified. But stick to it. You can scrap the plan, you can modify the plan or you can make a plan to fully replace the plan; but in every case, stick to your plan. He also suggested I read a book by Hal Rosenbluth entitled "The Customer Comes Second". The general message this book conveys is if you're running a business, run it YOUR way. It very much echoes Tom's sentiment of "stick to your plan". Have a vision. Work towards YOUR goals. Like that. (Interestingly, I later went to work at Rosenbluth International working 2 reports below Hal Rosenbluth. We had lunch a few times, I've been to his house. Interesting guy.)
So, for those of your gracious enough to put the effort and time into helping me bring MT to life and allowing me to test my Frankensteinian creations on your computers, thank you. Your feedback is all being cataloged and some of your suggestions are absolutely, positively being integrated into "the plan". But not in the short term. I know some of you are looking for specific features, and some of those ideas are definitely necessary to make MT "complete". I thank you for those ideas. Please... keep them coming. But also understand, I have to meter how I release the app and build versions and trickle-in new features. Some times they're not just bolt-on ideas; some times I have to go in and refactor core code.
This is what was causing me some frustration. I was looking too far into the future and too far out on the revisions. I was not sticking to my plan. I was getting frustrated and began questioning too many of my own choices. MT 1.0 may end up being a piece of crap that no one uses, but in the end I want it to be release as I had originally envisioned it, and I'll take my lumps and learn from my mistakes. This is, after all, a learning experience for me. Some new ideals in software design, some new coding paradigms, some new ways of how I think about software.
To sum up... thank you. Thank you for the feedback. Thank you for the patience. Thank you for the prodding. Start looking for new release announcements in the near future and start looking for new features to begin creeping in. There may be occasions where several releases don't have any apparent new features. They may simply be core enhancements that don't make it in to menu options or GUI components or full on features. I may simply be laying the ground work for later feature releases. But in all cases, rest assured, I'm getting back to it and things will begin progressing again.
Enjoy.
Friday, May 4, 2007
woes
I can NOT, for the life of me, design a freakin' report for the printout that looks good to me.
I know *what* I want, I just can't seem to actually make it happen on a form or in code. Very frustrating.
Just venting.... I'll get back to it when I'm not irked.
PS... I should also point out I have *no* idea what the "best" way to do this is, and I still have more reading to do :)
I know *what* I want, I just can't seem to actually make it happen on a form or in code. Very frustrating.
Just venting.... I'll get back to it when I'm not irked.
PS... I should also point out I have *no* idea what the "best" way to do this is, and I still have more reading to do :)
Tuesday, April 17, 2007
But really... what is "perfect" anyway?
My... ahem... "friends" reminded me yesterday that my Learn To Mac blog was in danger of atrophying. I tell ya... with friends like these, who needs an enema?
Anyway, I've been working on the Mac stuff as time allows. I've made some minor progress and gotten over a few of the smaller issues I had (press Enter to move to the next field, etc).
It's all going according to plan, if slowly. Sorry.
The main issue I'm having now is that my interface on Maintenance Tracker just doesn't feel "maccy" enough for me. It flows. It works. But it just doesn't feel like other Mac apps. I need to spend more time with Mac-like ergonomics articles and maybe a design book for the Mac developers. I'll get there. I'm a bright lad.
But I wanted to take a moment and vent a little. Let me preface all of this with a simple yet passionate statement; I'm all about the OS/X. I love it. And the whole Mac experience (and the accompanying "halo affect" of the other Mac products) is a great thing.
But nothing is perfect. This was a discussion that came up yesterday at work with the guys, and largely, I think people agree. One of the things that bothers me... nay, irks me... nay, that I absolutely, positively and undeniably hate... is the one thing that many Mac apps do.
When you click the little red "X" or round button the window closes but the application keeps running. I see it all the time on the Mac that the family uses. The apps are still running, even when - clearly - the user is done. When I close a document-based application's window, fine... close that window and leave the application running. That makes sense. Unless that window happens to be the last window of the session. Then just close the stupid application. Really.
End the clutter. Clean up the resources. Return the memory.
And it's really easy to do, in code and in the project settings. I don't understand it. Oh, I'm sure some people like that the app's engine is still sitting there idling, ready to pop up a new window at a moment's notice. But honestly, with modern disc-caching techniques, large memory pools and fast processors, is that really that big an issue?
Just close the freaking application if the app's last window closes. I think this makes sense, and it would go a long way towards appeasing users who don't understand the paradigm and for those users - like me - who like a tidy system.
And John made another excellent observation. In the dock, please don't show me the little arrow indicating that Finder is running. It's the main OS shell. Of course it's running. Probably the only time it isn't is when OS/X is running as am embedded system or in a kiosk. Specialized situations like that wouldn't necessarily need to present the user with a visible task list anyway.
So that should also go.
Anyway, I've been working on the Mac stuff as time allows. I've made some minor progress and gotten over a few of the smaller issues I had (press Enter to move to the next field, etc).
It's all going according to plan, if slowly. Sorry.
The main issue I'm having now is that my interface on Maintenance Tracker just doesn't feel "maccy" enough for me. It flows. It works. But it just doesn't feel like other Mac apps. I need to spend more time with Mac-like ergonomics articles and maybe a design book for the Mac developers. I'll get there. I'm a bright lad.
But I wanted to take a moment and vent a little. Let me preface all of this with a simple yet passionate statement; I'm all about the OS/X. I love it. And the whole Mac experience (and the accompanying "halo affect" of the other Mac products) is a great thing.
But nothing is perfect. This was a discussion that came up yesterday at work with the guys, and largely, I think people agree. One of the things that bothers me... nay, irks me... nay, that I absolutely, positively and undeniably hate... is the one thing that many Mac apps do.
When you click the little red "X" or round button the window closes but the application keeps running. I see it all the time on the Mac that the family uses. The apps are still running, even when - clearly - the user is done. When I close a document-based application's window, fine... close that window and leave the application running. That makes sense. Unless that window happens to be the last window of the session. Then just close the stupid application. Really.
End the clutter. Clean up the resources. Return the memory.
And it's really easy to do, in code and in the project settings. I don't understand it. Oh, I'm sure some people like that the app's engine is still sitting there idling, ready to pop up a new window at a moment's notice. But honestly, with modern disc-caching techniques, large memory pools and fast processors, is that really that big an issue?
Just close the freaking application if the app's last window closes. I think this makes sense, and it would go a long way towards appeasing users who don't understand the paradigm and for those users - like me - who like a tidy system.
And John made another excellent observation. In the dock, please don't show me the little arrow indicating that Finder is running. It's the main OS shell. Of course it's running. Probably the only time it isn't is when OS/X is running as am embedded system or in a kiosk. Specialized situations like that wouldn't necessarily need to present the user with a visible task list anyway.
So that should also go.
Thursday, March 22, 2007
I'm kind of stuck
I'm having a minor problem I can't seem to get around.
It's got to do with keystroke handling in editable table cells.
Specifically, I want to have the user hit ENTER after entering text, and simply have the editor exit the edit mode but leave the current cell/table entry/list entry as the selected item. By default, the ENTER key causes the next list element to be the currently selected item.
I don't want this. I want the user to have to TAB or arrow around, but pressing enter should just accept the text and leave the user's selected item alone. Or at least move horizontally across the table (where applicable). This is because in most cases, the only time the user will be editing text in the lists or tables is because he's entering a new item (new vehicle, new service record, new part entry). However if a user is entering a new entity, there is likely data outside the grid to be filled out as well. By using the default behavior of moving to the next list entry, the user has to manually click back on the new entity and it takes something away from the user experience. And it's just silly.
I can get *close*. I can get it to the point where it does what I want, but there are still artifacts on the screen. The redraw doesn't appear to be working, and I haven't found yet how to force it. I know I'm just missing something stupid, but I wanted to find the answer myself thru' research and trial-n-error. Unfortunately, either I'm the only person on the globe to have ever had this problem, or my Google-fu sucks. I'm voting the latter, but reserve the right to be wrong this time.
Anyway, that's about the last major hurdle before I release the next version - a version which brings along silly little polish and tuning points like this. No new features. I wanted to get a handle on these little niggling points early on.
So... look for a new release note soon. Right after I get un-stuck.
It's got to do with keystroke handling in editable table cells.
Specifically, I want to have the user hit ENTER after entering text, and simply have the editor exit the edit mode but leave the current cell/table entry/list entry as the selected item. By default, the ENTER key causes the next list element to be the currently selected item.
I don't want this. I want the user to have to TAB or arrow around, but pressing enter should just accept the text and leave the user's selected item alone. Or at least move horizontally across the table (where applicable). This is because in most cases, the only time the user will be editing text in the lists or tables is because he's entering a new item (new vehicle, new service record, new part entry). However if a user is entering a new entity, there is likely data outside the grid to be filled out as well. By using the default behavior of moving to the next list entry, the user has to manually click back on the new entity and it takes something away from the user experience. And it's just silly.
I can get *close*. I can get it to the point where it does what I want, but there are still artifacts on the screen. The redraw doesn't appear to be working, and I haven't found yet how to force it. I know I'm just missing something stupid, but I wanted to find the answer myself thru' research and trial-n-error. Unfortunately, either I'm the only person on the globe to have ever had this problem, or my Google-fu sucks. I'm voting the latter, but reserve the right to be wrong this time.
Anyway, that's about the last major hurdle before I release the next version - a version which brings along silly little polish and tuning points like this. No new features. I wanted to get a handle on these little niggling points early on.
So... look for a new release note soon. Right after I get un-stuck.
Subscribe to:
Posts (Atom)
