I'm no longer a part of the Redshirt Labs gang of 5 that was actually 4 for quite a while and felt like 2 for a long time, but whatever. I'm done. Of course we still hang out and eat the same lunch at Prince Al's, but no longer will I be pining over what to do next with Zengaku. The rest of the gang will figure it out. I'd offered to take it off there hands, but they didn't go for that. I also considered licensing the source code and doing a fork, but I reconsidered and felt like a clean break would be best.
So begins the adventure once more. This time with a little more solitude. But if I make an application that only sells a few hundred dollars worth on the market, that's a bit easier to swallow than when you have to split that 5 ways. Plus I'm not going to be making games. Which I think would be fun, but is a tough business to get into and requires a lot of talent that I don't have. Mainly a lot of art, music, sound and game design skills. I could probably implement the code for a game if you gave me the spec/design docs, but coming up with all the rest is way to much for me and I can't go and hire all that talent either. This is just a hobby after all.
So I've made the initial steps of setting up my new business. I've got an idea for a first application. I'll share that soon enough. I got a website, a hosting service, a remote repository and an official business license. I'm working on my registration with the Apple Developer Program. It's all getting started. Now to start making the application. My hope is to have it delivered to the App Store before the Christmas holidays. Not that it would help sales or anything, just that I need a goal and that seemed reasonable.
I'm not going to get into the details of my business idea, or the application I plan to build just yet. If you ask me in person I'll tell you about it. But mostly I'm just not ready to share much else at this point. I have a lot of work to do. I'd like to have a decent landing page on my website, get some blog content lined up, get the application in progress and moving forward and so on and so forth. Then I'll have loads more to talk about. But for now this is about it.
I may have to write a bit about my new affection for JavaScript and functional programming. I don't know if I'd say I know a lot about either just yet, but I've definitely spent some time getting familiar with JavaScript over the last couple months and I'm actually quite impressed. But also looking forward to doing a bit of C/C++ work once more.
Friday, September 23, 2011
Wednesday, March 30, 2011
A couple of things Developers Should Know but often Don't
I've been reviewing a lot of code lately. Mostly Java code, but some C, some C++ event some Objective C. There have been some patterns to the coding mistakes/miss-steps that I've seen and been pointing out in a number of these review.
Loops
This one seem to be the most common of late. And I had to convince some people of the merit of my stance. Basically my theory is that you should almost never need a while loop. So if you ever see yourself using one. Ask yourself why. Most times you'll be declaring some kind of iteration tracking variable and incrementing or updating it somehow as you loop through whatever structure is being iterated over.
The problem there is that the variable gets declared and used outside the loop. Now C doesn't help here so it's common for C developers to make this mistak in languages that do help. In my case Java. Using a for loop allows you to declare a variable that is scoped to you loop so you can be sure you don't accidentally keep the variable longer than you need and use it by accident somewhere else in your function.
I think the latest C standard (C99) fixes this, but it's pretty common that you can't count on that so a lot of C developers still don't think about this feature. Just about the only time I think a while loop is a bit cleaner or clearer is if you are creating an infinite loop; in that case the simple while(true){} is pretty universal. Although I've seen for(;;){} a number of times as well so I'm still not sold on that.
Proper Scope
Along the same lines as my previous issue with loops is ensuring that your variables are scoped properly. I hate seeing Java functions with a long, long laundry list of auto variables that are potentially not needed since the the parameters may make their allocation unnecessary. Although this isn't really a memory or optimization effort it does help a bit in that respect. The Java stack frame will be allocated with space for all the local variables. Event the objects, although only space for the reference is allocated by default.
So although you will not be preventing local variables from being allocated, if you have the the objects you create properly scoped they will at least only do the object allocation when needed and will be dereference and available for GC as soon as possible. But the optimization can come into play if your objects are only going to be created if certain parameters are passed into that method. So in cases where your parameters don't require the objects to be created you save that time and memory. But like I said, this isn't really the reason to scope them properly.
The best reason for scoping variables is for clarity and maintenance. The issue with keep a variable around longer than you need to is that it is unclear if you intended to use it later and just forgot, or worse yet you do use it later, but didn't actually mean to do so. Don't laugh. This happens a lot. In particular in long, hairy functions. I don't like those either, but baby steps.
Over use of if this set this else set that
I think this is a pretty easy one. Which would you think is clearer and more concise:
Option 1:
if (conditiona) {
var = boo;
}
else {
var = bar;
}
Option 2:
var = (conditional) boo : bar;
Option 2 is the clear winner in my books hands down every time. I think this is the very reason why the ternary operator gets included in pretty much every language I've had the pleasure of working with.
I have lots of other gripes and faux paus that I see on a daily basis, but these are just some of the most common that I've seen of late. One of my biggest pet peeves is when OO design gets perverted into some crazy mess of over complicated goo. Often that seems to start with good intentions and the classic over use of inheritance rather than composition. I've trained myself similar to the for loop to stop every time I see inheritance to ask if it is actually the most appropriate solution to the problem at hand and if it truly adds value beyond what composition could provide. I feel like I'm stating the obvious since I've been reading about this stuff on blogs like this for years, but I keep seeing these same issues in the code I look at being created on a daily basis so people still aren't getting the message. I figured I may as well add to the ocean of data out there pleading with developers to clean things up. But I'm sure it's a Sisyphus like task. But I'll keep pushing that damn rock anyway. It's just how I roll.
Loops
This one seem to be the most common of late. And I had to convince some people of the merit of my stance. Basically my theory is that you should almost never need a while loop. So if you ever see yourself using one. Ask yourself why. Most times you'll be declaring some kind of iteration tracking variable and incrementing or updating it somehow as you loop through whatever structure is being iterated over.
The problem there is that the variable gets declared and used outside the loop. Now C doesn't help here so it's common for C developers to make this mistak in languages that do help. In my case Java. Using a for loop allows you to declare a variable that is scoped to you loop so you can be sure you don't accidentally keep the variable longer than you need and use it by accident somewhere else in your function.
I think the latest C standard (C99) fixes this, but it's pretty common that you can't count on that so a lot of C developers still don't think about this feature. Just about the only time I think a while loop is a bit cleaner or clearer is if you are creating an infinite loop; in that case the simple while(true){} is pretty universal. Although I've seen for(;;){} a number of times as well so I'm still not sold on that.
Proper Scope
Along the same lines as my previous issue with loops is ensuring that your variables are scoped properly. I hate seeing Java functions with a long, long laundry list of auto variables that are potentially not needed since the the parameters may make their allocation unnecessary. Although this isn't really a memory or optimization effort it does help a bit in that respect. The Java stack frame will be allocated with space for all the local variables. Event the objects, although only space for the reference is allocated by default.
So although you will not be preventing local variables from being allocated, if you have the the objects you create properly scoped they will at least only do the object allocation when needed and will be dereference and available for GC as soon as possible. But the optimization can come into play if your objects are only going to be created if certain parameters are passed into that method. So in cases where your parameters don't require the objects to be created you save that time and memory. But like I said, this isn't really the reason to scope them properly.
The best reason for scoping variables is for clarity and maintenance. The issue with keep a variable around longer than you need to is that it is unclear if you intended to use it later and just forgot, or worse yet you do use it later, but didn't actually mean to do so. Don't laugh. This happens a lot. In particular in long, hairy functions. I don't like those either, but baby steps.
Over use of if this set this else set that
I think this is a pretty easy one. Which would you think is clearer and more concise:
Option 1:
if (conditiona) {
var = boo;
}
else {
var = bar;
}
Option 2:
var = (conditional) boo : bar;
Option 2 is the clear winner in my books hands down every time. I think this is the very reason why the ternary operator gets included in pretty much every language I've had the pleasure of working with.
I have lots of other gripes and faux paus that I see on a daily basis, but these are just some of the most common that I've seen of late. One of my biggest pet peeves is when OO design gets perverted into some crazy mess of over complicated goo. Often that seems to start with good intentions and the classic over use of inheritance rather than composition. I've trained myself similar to the for loop to stop every time I see inheritance to ask if it is actually the most appropriate solution to the problem at hand and if it truly adds value beyond what composition could provide. I feel like I'm stating the obvious since I've been reading about this stuff on blogs like this for years, but I keep seeing these same issues in the code I look at being created on a daily basis so people still aren't getting the message. I figured I may as well add to the ocean of data out there pleading with developers to clean things up. But I'm sure it's a Sisyphus like task. But I'll keep pushing that damn rock anyway. It's just how I roll.
Sunday, March 6, 2011
Samsung's Lost a Customer Today
I have a Samsung HTDV. I was quite happy with it until recently. It started to behave rather oddly when I powered it on. I'd hear this relay clicking sound repeatedly before it actually powered on. At first this happened for 2 or 3 cycles. Then it was 10, then 20, then it was starting to take upwards of 5 minutes before the TV would actually turn on.
This started around the time my 1st child was born so my time for such distractions was at a minimum. I finally decided to look up on the inter-webs to see if others had seen this problem and maybe there would be a quick fix. I soon found that this seems to have been a common issue with a number of Samsung LCD TVs with my model number. They called it the "bad capacitor issue". Apparently they installed some sub-standard capacitors that eventually wore out. As the issue progresses eventually your TV would never power on again until the faulty capacitors are replaced.
So I looked up the Samsung support site and called the support group. They told me I had to provide my proof of purchase and fax it to them. And so I did. But after all that I found out that since I've owned my TV for longer than 3 years I don't qualify according to Samsung's policy on the matter. I said: "That's fine, but it's my policy that if a company doesn't want to fix a product issue that is obviously due to an error on their part, they'll lose me as a customer." The service rep just stuck to the script and said: "Sorry, but this is Samsung's policy." I don't care if that's the policy. After this experience Samsung's not going to get another dime from me. It's too bad too.
I had heard over and over again that they had a quality product. But this is all it takes to really sour a customer on your products. I wouldn't have minded if they'd just offered to fix the issue and replace the capacitors at fault. But that's just not the story I'm telling you today. I'd rather be praising them. But I'm not. Instead you're reading this little buyer beware story. Oh well. When I decided to get a new TV I wonder who's going to be getting my money. Maybe Apple will finally have produced a real Apple TV product. One can dream.
This started around the time my 1st child was born so my time for such distractions was at a minimum. I finally decided to look up on the inter-webs to see if others had seen this problem and maybe there would be a quick fix. I soon found that this seems to have been a common issue with a number of Samsung LCD TVs with my model number. They called it the "bad capacitor issue". Apparently they installed some sub-standard capacitors that eventually wore out. As the issue progresses eventually your TV would never power on again until the faulty capacitors are replaced.
So I looked up the Samsung support site and called the support group. They told me I had to provide my proof of purchase and fax it to them. And so I did. But after all that I found out that since I've owned my TV for longer than 3 years I don't qualify according to Samsung's policy on the matter. I said: "That's fine, but it's my policy that if a company doesn't want to fix a product issue that is obviously due to an error on their part, they'll lose me as a customer." The service rep just stuck to the script and said: "Sorry, but this is Samsung's policy." I don't care if that's the policy. After this experience Samsung's not going to get another dime from me. It's too bad too.
I had heard over and over again that they had a quality product. But this is all it takes to really sour a customer on your products. I wouldn't have minded if they'd just offered to fix the issue and replace the capacitors at fault. But that's just not the story I'm telling you today. I'd rather be praising them. But I'm not. Instead you're reading this little buyer beware story. Oh well. When I decided to get a new TV I wonder who's going to be getting my money. Maybe Apple will finally have produced a real Apple TV product. One can dream.
Globe & Mail talks about Cord Cutting
I was reading the Globe & Mail a couple weeks ago in between feeding my newborn daughter and catching up on sleep. The article in question was this one: Globe & Mail - This is Where we Leave Cable Behind. I found it pretty interesting given my past experiences within the cable business. I'd expected the article to be all about digital streaming over the internet, but rather it talked more about how digital cable is slowly being supplanted by the newer and cooler sounding IPTV.
The majority of the article talked about how IPTV is being deployed aggressively by a number of telecom companies to go on the offensive vs. the big canadian cable stalwarts. And it seems that despite the limited footprint of the product they are making inroads. This is basically the Telco's punch in the nose after getting bullied by the cable folks for so long in the realm of mobile phones.
The part of the article that I latched onto was when it was quoting from someone they'd interviewed who was using the IPTV service from one of the providers. The whole article was talking about the great new features and web-like experience that this new IPTV technology could provide. But at the moment the offerings provided in these early markets where the service is available they have a very cable-like experience thus far. And the guy they are interviewing doesn't really care about that. What he's excited about despite all that is the fact that the program guide and other software that he interacts with on the device provides a user experience more like what you'd expect from a product built in the last 4 or 5 years and not like it was built in the 80's using Atari games as the design aesthetic.
If I were a cable operator...and I'm not, but if I were I might want to consider getting a new program guide experience as soon as possible. I know my feelings are similar to the guy in the Globe's article. If my provider had a much nicer user interface with a well laid out and simple flow of control for searching, browsing and discovering content on my TV I'd be a lot more satisfied than I am today. So what I'm saying is that in terms of short term bang for the buck the cable companies really should consider just giving their guides a real facelift. Let a real designer go to town on it. Let a real software company build it for you and deploy, deploy, deploy.
I'm not saying that IPTV is a waste of time. Not at all. I believe it's likely where all paid TV is going to go and needs to go. But it's more of a longer term strategic thing as far as I can tell. But if they want to stop the bleeding. And I'm thinking they do, they would be well served to bring their guides into the 21st century. They don't even need to add new features....just make the ones they already have work better.
I'd love to be a cord cutter, but my morality gets in the way...
I have a hard time with "cord-cutting". I would love to stop giving my service provider so much money for a service that I think I'm over-paying for, but I also don't have a clear alternative that provides the same level of service without going outside the law. The frustrating part isn't that no one else can provide the service at the same level of quality or even better. It's that government regulations and the entrenched telecom companies keep blocking competition any chance they get.
Just across the boarder services such as Hulu, Amazon On Demand, VUDU, and others provide access to a lot of high quality streamed content that I can't have for a number of political and legal reasons. I could do as a number of my tech savvy friends have done and setup a Usenet account or use Bit torrents to get at the content I'd like. Or more recently some have tried services which allow you access to US services through a VPN like service so the service provided doesn't detect you aren't in the US and as such allows you to stream content to you're hearts content. The last option is probably the most morally ambiguous. The first 2 are pretty clearly stealing. And I have a hard time with that since I love the content. I want to pay those who produced it their due. They provided me the entertainment value and I feel obligated to pay them for that value. This is why the last option is more palatable to me. At least in that case the producers of the content are still getting paid. You're just subverting their contract with the contents owners to not distribute the content outside certain geographic boundaries.
I find that as time passes and things like UBB have come to a head my moral arguments are carrying less and less weight with me. I'm starting to feel like the only way we'll be able to change the way video content is delivered is to hurt them where it seems to matter most, even if that will in turn still hurt me, in that the content I love may not have the funds to be produced any more. I could quite easily sign up for a Usenet service, pick up a Mac Mini with HDMI out and install Plex or another XBMC varient quite easily. I know the programs to install that can automatically download the content I'd want and it's all pretty easy to find.
However it's not all doom and gloom. There's still a chance that my provider will learn something here. For me the UI and the UX matter a great deal more than the feature list. If they can just spend some time focusing on that they would find someone like me a lot easier to please. They already provide a pretty impressive feature set. I can deal with VOD shows that are handcuffed by not allowing me to fast-forward through the commercials. I can also deal with a DVR that doesn't have all the bells and whistles that a TiVo can provide. Just make it easier to use, make it drop fewer scheduled recordings, make it easier for me to find the VOD content you have, and make it not so horribly ugly to look at on my big screen TV. I don't think I'm asking for too much here.
The majority of the article talked about how IPTV is being deployed aggressively by a number of telecom companies to go on the offensive vs. the big canadian cable stalwarts. And it seems that despite the limited footprint of the product they are making inroads. This is basically the Telco's punch in the nose after getting bullied by the cable folks for so long in the realm of mobile phones.
The part of the article that I latched onto was when it was quoting from someone they'd interviewed who was using the IPTV service from one of the providers. The whole article was talking about the great new features and web-like experience that this new IPTV technology could provide. But at the moment the offerings provided in these early markets where the service is available they have a very cable-like experience thus far. And the guy they are interviewing doesn't really care about that. What he's excited about despite all that is the fact that the program guide and other software that he interacts with on the device provides a user experience more like what you'd expect from a product built in the last 4 or 5 years and not like it was built in the 80's using Atari games as the design aesthetic.
If I were a cable operator...and I'm not, but if I were I might want to consider getting a new program guide experience as soon as possible. I know my feelings are similar to the guy in the Globe's article. If my provider had a much nicer user interface with a well laid out and simple flow of control for searching, browsing and discovering content on my TV I'd be a lot more satisfied than I am today. So what I'm saying is that in terms of short term bang for the buck the cable companies really should consider just giving their guides a real facelift. Let a real designer go to town on it. Let a real software company build it for you and deploy, deploy, deploy.
I'm not saying that IPTV is a waste of time. Not at all. I believe it's likely where all paid TV is going to go and needs to go. But it's more of a longer term strategic thing as far as I can tell. But if they want to stop the bleeding. And I'm thinking they do, they would be well served to bring their guides into the 21st century. They don't even need to add new features....just make the ones they already have work better.
I'd love to be a cord cutter, but my morality gets in the way...
I have a hard time with "cord-cutting". I would love to stop giving my service provider so much money for a service that I think I'm over-paying for, but I also don't have a clear alternative that provides the same level of service without going outside the law. The frustrating part isn't that no one else can provide the service at the same level of quality or even better. It's that government regulations and the entrenched telecom companies keep blocking competition any chance they get.
Just across the boarder services such as Hulu, Amazon On Demand, VUDU, and others provide access to a lot of high quality streamed content that I can't have for a number of political and legal reasons. I could do as a number of my tech savvy friends have done and setup a Usenet account or use Bit torrents to get at the content I'd like. Or more recently some have tried services which allow you access to US services through a VPN like service so the service provided doesn't detect you aren't in the US and as such allows you to stream content to you're hearts content. The last option is probably the most morally ambiguous. The first 2 are pretty clearly stealing. And I have a hard time with that since I love the content. I want to pay those who produced it their due. They provided me the entertainment value and I feel obligated to pay them for that value. This is why the last option is more palatable to me. At least in that case the producers of the content are still getting paid. You're just subverting their contract with the contents owners to not distribute the content outside certain geographic boundaries.
I find that as time passes and things like UBB have come to a head my moral arguments are carrying less and less weight with me. I'm starting to feel like the only way we'll be able to change the way video content is delivered is to hurt them where it seems to matter most, even if that will in turn still hurt me, in that the content I love may not have the funds to be produced any more. I could quite easily sign up for a Usenet service, pick up a Mac Mini with HDMI out and install Plex or another XBMC varient quite easily. I know the programs to install that can automatically download the content I'd want and it's all pretty easy to find.
However it's not all doom and gloom. There's still a chance that my provider will learn something here. For me the UI and the UX matter a great deal more than the feature list. If they can just spend some time focusing on that they would find someone like me a lot easier to please. They already provide a pretty impressive feature set. I can deal with VOD shows that are handcuffed by not allowing me to fast-forward through the commercials. I can also deal with a DVR that doesn't have all the bells and whistles that a TiVo can provide. Just make it easier to use, make it drop fewer scheduled recordings, make it easier for me to find the VOD content you have, and make it not so horribly ugly to look at on my big screen TV. I don't think I'm asking for too much here.
Tuesday, November 23, 2010
Buzz Comments Degraded into a Mac App Store Sucks Battle Royal
So I've been wanting to post this discussion for a while and just haven't got around to doing so. It was a discussion that happened on Google Buzz a while back where one person posted a link that talked about all the things that flash can do that HTML5 cannot. It then degraded into an Apple sucks festival to which I wasn't really invited and was summarily dejected from. Although I could have probably picked a better leg to stand on since I'm not the biggest fan of XCode (although XCode 4 does seem to be a pretty substantial improvement). Anyway I hope someone finds this conversation as amusing as I did. I've posted the full comment history with the names of those who are not me edited out. Everything else is as it was in the discussion...bad grammer, bad spelling et al.
Commenter #1 - Dropping Flash support was such a bad move. And now dropping Java support is even worse. I honestly think Jobs might have gone crazy. Or, he's a Cylon.Oct 29
Commenter #2 - I kind of see a possible reasoning for it. Apple has always benefited from not being too popular; people didn't care enough about macs to write viruses for it, etc. Standard security through obscurity. Now that it's growing, people are starting to care and are using attack vectors being found for macs through trusted public script interpreters like java/flash/etc. It doesn't matter that the interpreters run in the user space and the vulnerabilities are in OS X. Jobs will push the blame elsewhere. So by discontinuing support for anything they don't explicitly approve of (upcoming mac app store), they can continue to falsely claim that they're "secure" because of their walled garden. "you're safe because we only give you approved crayons and safety scissors".
I'm interested to see if they start voiding mac warranties for installing applications that aren't in the mac store because they can compromise system security (like jailbreaking iphones).Oct 29
I'm interested to see if they start voiding mac warranties for installing applications that aren't in the mac store because they can compromise system security (like jailbreaking iphones).Oct 29
Commenter #3 - I can't believe that even mac fanboys are into the idea of an imac store... I also can't imagine that developers are too keen to have to share 20% of their income with apple in a space where they previously didn't have to share anything with anyone.Oct 29
Commenter #2 - But now there's the argument that a store will help smaller developers that won't need separate publishers etc. 70% is better than 0. I'm guessing (completely on whimsical speculation) that there would be a paid Apple-certification process for large companies that want to be supported with a one-time fee.Oct 29
Kevin Hendry - If by 20% you mean 30% I'd agree.Oct 29
Commenter #3 - good point. As a dyed-in-the-wool apple fan; what is your take on the iMac app store? Do you think it's a good thing or a bad thing? Do you think Jobs is going to go insane a look future iOS releases to only allowed apps from the supported store - and if that happens will you switch away from apple or smile and tell everyone that you love it?Oct 29
Kevin Hendry - Also it isn't exactly true that they get everything now. They pay for other services to manage the payment systems and they have to pay to maintain those systems if they decide to build them...which most can't afford to do. Plus the idea would be similar to that with the mobile store where a common place for application discovery may spur enough traffic and business to offset the increased percentage take that Apple gets. If it works. Also it provides a greatly simplified interface for payments compared to go-it-alone options. However I'm pretty skeptical it will work unless they loosen up the restrictions more than they have thus far.Oct 29
Kevin Hendry - IF it starts to prove that monies can be made like the mobile store did, there will be a lot of new crazy applications for the Mac we've not seen or thought of yet. But similar to TV I don't know if the medium is all that ripe for a lot of creativity.Oct 29
Kevin Hendry - Also if Apple actually starts to lock down the Mac platform similar to what they've got on the mobile devices I think it will flop. I need my Mac to be open enough for a number of tools to work on it. It is a swiss army knife of sorts. The phone being an embedded device I can understand why it is more restricted. But a PC cannot have those same restrictions other wise its a tablet.Oct 29
Commenter #2 - Isn't the industry moving closer to a tablet-like experience? Multi-touch / Chrome OS / dumbed down netbook UI's / etc? Most people just need access to their "google internet" and their fart apps.Oct 29
Commenter #1 - Haha. Sadly, I think you're right BC.Oct 29
Kevin Hendry - Yes, for a large number of average consumers iPad like devices are on the way, but they still need machines to develop the code on at some point. Part of Apples recent success is due to a number of moves it made to modernize its development environment, and the OSX platform (not just the GUI). Things like CLANG (via LLVM), WebKit, Grand Central Dispatch, Blocks for C (and possibly the next C spec). These things get developers excited about building code on their platform. I'm certainly disconcerted that they've deprecated their Java port, but I think it's probably better if that is supported via the community regardless.
They have to keep building machines & technologies that developers want to build code on top of...not just consumption devices for the masses. The nice thing is that they're building application/media consumption devices that are popular and they're providing a good development platform us to make monies with. If they were to remove the pillar of the development platform by restricting the options available to developers they will likely lose them in droves. I believe that since I think that although everyone likes to make money, mostly developers like other things and if you piss them off enough they'll walk away from the money in the short term and probably make you regret it. I don't think Apple is going to lock things down on the Mac....but they might...and I think they'd pay dearly for such a mistake.Oct 29
They have to keep building machines & technologies that developers want to build code on top of...not just consumption devices for the masses. The nice thing is that they're building application/media consumption devices that are popular and they're providing a good development platform us to make monies with. If they were to remove the pillar of the development platform by restricting the options available to developers they will likely lose them in droves. I believe that since I think that although everyone likes to make money, mostly developers like other things and if you piss them off enough they'll walk away from the money in the short term and probably make you regret it. I don't think Apple is going to lock things down on the Mac....but they might...and I think they'd pay dearly for such a mistake.Oct 29
Commenter #2 - If Steve Jobs sucker punched his average fan, they'd probably thank him for the "real" experience he just gifted them. He presents a smaller netbook that costs a thousand dollars with minimal specs, and the reviews are glowing because it's small and it "just screams" for everyday tasks. Apple already treats developers and device owners like worthless piles of waste, and they stick with it because ..... well, I don't know why. But they do.
I've already stated that the locked-down mac strategy was completely wild speculation, but for the sake of fun I'm going to continue with it. Developers already have to pay, what is it, $100 to be able to make apps for iCrap devices. Who's to say that they wouldn't put a similar idea to use with mac development kits? It, itself, could be an approved app in iTunes. And part of the sdk could be a sandboxed environment for testing code, so you wouldn't void your warranty by running non-approved code directly on Apple's hardware (that you have the privilege of having in your house).
Anyhow, just a fun thought exercise. I'm sure that in reality they'll be far more creative in finding ways to fuck over their client base while being thanked for it.
I need TimmiesOct 31
I've already stated that the locked-down mac strategy was completely wild speculation, but for the sake of fun I'm going to continue with it. Developers already have to pay, what is it, $100 to be able to make apps for iCrap devices. Who's to say that they wouldn't put a similar idea to use with mac development kits? It, itself, could be an approved app in iTunes. And part of the sdk could be a sandboxed environment for testing code, so you wouldn't void your warranty by running non-approved code directly on Apple's hardware (that you have the privilege of having in your house).
Anyhow, just a fun thought exercise. I'm sure that in reality they'll be far more creative in finding ways to fuck over their client base while being thanked for it.
I need TimmiesOct 31
Friday, November 19, 2010
Teleported
 |
| Our Team Logo |
I think I'll have to do some follow up posts with my thoughts on what these guys did well and why I think they gelled together and created a culture all their own. Also I should talk about the problems this caused and the issues they had in dealing with other teams in the company and my take on some of the things they never quite got right. But mostly this points is just about me remembering just how much fun that whole experience was and how important my relationship to those guys is to me still.
Thanks Mark for Teleporting me back for a while. Here's a recap of our little list of Teleporter goofy sayings just in case you're curious. I"ll try to explain in comments if any of you are interested enough to ask.
- "That's not a magnet!" - Tom
- "The comma will protect us all." - Andrew
- "That's harass." - Peng
- "Set to the OR of the NOTs." - Tom
- "There's no GC in C." - Tom
- "Laser solids" - Peng
- "Monkey peaches" - Peng
- "Set how many big?" - Tim
- "Undo the did." - Tom
- "The designees are sad." - Mark
- "Make like the regression and break." - Andrew
- "Make from for the bind bits!" - Tim
- "Evil smell." - Peng
- "Groupe Ide" (pronounced group-eh ee-day) - Tim & Andrew
- "That's so awkward" - Peng (said whenever someone spills something on their pants)
Sunday, November 14, 2010
Subverted
My experience with version control systems, revisions control systems, configuration management systems or whatever you happen to call them primarily consisted of Perforce while at Liberate/TVWorks. I spent some time dealing with Visual Source Safe before that. Perforce felt like it was from the future after that experience.
As I moved into more of a team lead and architect role at TVWorks I spent less and less time committing code. Then Comcast management decided that we should be using common tools across the various entities working on software products for Comcast's video services. For all intents and purposes this consisted of TVWorks in London, TVWorks in Mill Valley and Guideworks in Radnor. There are other players, but they didn't seem to be included in the quest to use common tools. Regardless this yielded yet another change in revision control system for me. This time the move was to Subversion. But since I wasn't doing development any longer my experience with Subversion was pretty limited. Switching to Subversion made a co-worker of mine was quite excited for some reason, but not because we were using Subversion, but what doing that allowed us to use. Git.
Upon him explaining Git and taking some time to read up on the tool myself I decided that my interactions with Subversion would be through a Git front end that my co-worker had told me about. Doing so proved quite problematic for me due to a number of non-standard repositories I had to interact with...also the rather bloated size of the repositories made Git choke more than once while using Cygwin. I had more success natively on Linux, but still working with git-svn and the CableLabs repository structure was a real pain and I'd generally opted for the script they'd created to complete a sparse checkout of a branch.
As such I became familiar with Git and its interface to SVN, but not really proficient at either one. We decided to make use of GitHub and a private repo for our code at Redshirt Labs as well. This also allowed me to learn quite a bit more about Git and the work flow it allowed you to use. Although my interaction was pretty limited again since my role within Redshirt Labs was more about getting all the other partners to focus long enough to produce our application than doing a lot of application development myself. I drove meetings, worked our agenda's, found someone to do the creative work, helped limit the initial feature set and set milestones. Not much development there.
Nowadays I'm getting right down to development once again. I've been working hard to make Zengaku a universal application that can run properly on both the iPad and the iPhone/iPod Touch. I've been figuring out how to manipulate the interface to handle orientation changes and creating a lot of new artwork with a lot of help from my sister-in-law. The point is I've been getting quite familiar with Git now and really liking what I see.
At my day job, or at least on the project I'm working on, we use Subversion. Once again this is actually working with Comcast and CableLabs coincidentally. I'm still trying to figure out the best ways to make git-svn work in this situation. In part due to the Big-Ass-Checking problem I've had. Using Git and a local repo that I can checkin to makes me feel a lot better while I'm developing and is generally pretty quick to work with. However the crazy SVN layout still gives me loads of trouble.
I've also learned a few new things about SVN that I didn't realize. Apparently you can swap branches in SVN like you can in git. This was totally news to me since it was a big reason why I liked working with Git. I'd never seen any tutorial or blog talking about this particular feature of Subversion. Apparently all you need to do is call: 'svn switch'. You have to specify the URL of the branch you are switching to so it isn't as nice as: 'git checkout <branch>'. But it would do the job. I've tried it a few times and it does generally work, although it has failed mid switch more than once...trying again allowed it to complete.
I also learned that SVN is more efficient than I'd been led to believe in that creating a branch is a very inexpensive operation. It is more akin to creating a soft link than creating a new branch. This has some problems for me since the branches that are created end up just being complete copies of the entier repository which seems less than ideal since you have a large amount of code that has nothing to do with what the branch is about a lot of the time. In particular when we are talking about the CableLabs tru2way repository. The other thing I didn't realize about Subversion is that when you merge change from a branch back to the main or trunk you lose the individual submissions that got you to that point. Unless you keep the branch around (which you could, but would make for a rather wild tree after a while). When I found this out it really made me scratch my head since at this point I'd though that since Git didn't have such a problem, subversion surely wouldn't either. But as my co-worker pointed out...I kinda jumped the queue and when straight to go collecting my $200 with Git. I never really had to live with Subversion so I just assumed that the Git way was the way things should be done.
This was a bit of a meandering post that ended up way, way longer than I thought it would. But I'm going to share it anyway. Hope someone findes it interesting and maybe finds out something new as well. I might talk more about how I'm managing to use Git in our current environment in a later post.
There was some chatter that CableLabs might be considering a move to Git, but I'm not really hopeful. Although it would definitely make my life a lot easier.
As I moved into more of a team lead and architect role at TVWorks I spent less and less time committing code. Then Comcast management decided that we should be using common tools across the various entities working on software products for Comcast's video services. For all intents and purposes this consisted of TVWorks in London, TVWorks in Mill Valley and Guideworks in Radnor. There are other players, but they didn't seem to be included in the quest to use common tools. Regardless this yielded yet another change in revision control system for me. This time the move was to Subversion. But since I wasn't doing development any longer my experience with Subversion was pretty limited. Switching to Subversion made a co-worker of mine was quite excited for some reason, but not because we were using Subversion, but what doing that allowed us to use. Git.
Upon him explaining Git and taking some time to read up on the tool myself I decided that my interactions with Subversion would be through a Git front end that my co-worker had told me about. Doing so proved quite problematic for me due to a number of non-standard repositories I had to interact with...also the rather bloated size of the repositories made Git choke more than once while using Cygwin. I had more success natively on Linux, but still working with git-svn and the CableLabs repository structure was a real pain and I'd generally opted for the script they'd created to complete a sparse checkout of a branch.
As such I became familiar with Git and its interface to SVN, but not really proficient at either one. We decided to make use of GitHub and a private repo for our code at Redshirt Labs as well. This also allowed me to learn quite a bit more about Git and the work flow it allowed you to use. Although my interaction was pretty limited again since my role within Redshirt Labs was more about getting all the other partners to focus long enough to produce our application than doing a lot of application development myself. I drove meetings, worked our agenda's, found someone to do the creative work, helped limit the initial feature set and set milestones. Not much development there.
Nowadays I'm getting right down to development once again. I've been working hard to make Zengaku a universal application that can run properly on both the iPad and the iPhone/iPod Touch. I've been figuring out how to manipulate the interface to handle orientation changes and creating a lot of new artwork with a lot of help from my sister-in-law. The point is I've been getting quite familiar with Git now and really liking what I see.
At my day job, or at least on the project I'm working on, we use Subversion. Once again this is actually working with Comcast and CableLabs coincidentally. I'm still trying to figure out the best ways to make git-svn work in this situation. In part due to the Big-Ass-Checking problem I've had. Using Git and a local repo that I can checkin to makes me feel a lot better while I'm developing and is generally pretty quick to work with. However the crazy SVN layout still gives me loads of trouble.
I've also learned a few new things about SVN that I didn't realize. Apparently you can swap branches in SVN like you can in git. This was totally news to me since it was a big reason why I liked working with Git. I'd never seen any tutorial or blog talking about this particular feature of Subversion. Apparently all you need to do is call: 'svn switch'. You have to specify the URL of the branch you are switching to so it isn't as nice as: 'git checkout <branch>'. But it would do the job. I've tried it a few times and it does generally work, although it has failed mid switch more than once...trying again allowed it to complete.
I also learned that SVN is more efficient than I'd been led to believe in that creating a branch is a very inexpensive operation. It is more akin to creating a soft link than creating a new branch. This has some problems for me since the branches that are created end up just being complete copies of the entier repository which seems less than ideal since you have a large amount of code that has nothing to do with what the branch is about a lot of the time. In particular when we are talking about the CableLabs tru2way repository. The other thing I didn't realize about Subversion is that when you merge change from a branch back to the main or trunk you lose the individual submissions that got you to that point. Unless you keep the branch around (which you could, but would make for a rather wild tree after a while). When I found this out it really made me scratch my head since at this point I'd though that since Git didn't have such a problem, subversion surely wouldn't either. But as my co-worker pointed out...I kinda jumped the queue and when straight to go collecting my $200 with Git. I never really had to live with Subversion so I just assumed that the Git way was the way things should be done.
This was a bit of a meandering post that ended up way, way longer than I thought it would. But I'm going to share it anyway. Hope someone findes it interesting and maybe finds out something new as well. I might talk more about how I'm managing to use Git in our current environment in a later post.
There was some chatter that CableLabs might be considering a move to Git, but I'm not really hopeful. Although it would definitely make my life a lot easier.
Subscribe to:
Posts (Atom)