Wednesday, March 30, 2016
Monday, February 29, 2016
Lunchtime at The Movies
Well, not exactly at the movies (although that would be nice). I've started doing something at work to try and socialize and spark discussion on either technical things or the process of building software types of things. It's a divergence from the occasional post stand-up video showing off some insane accomplishment someone does in a car, or on a motorcycle, or skateboard, or bicycle. It's a bit more serious than that, and for good reason.
One of the great things about working with a team of good people (and by good I mean you care about producing useful stuff and helping out your fellow humanzies) is that everyone has been exposed to different things, have differing bases [bey-seez] of knowledge, and hold their own ideas about technology and the world. You may find out about them either through pairing with folks, coming together as a larger team to solve a problem, over coffee, or on a team outing.
Another avenue is over lunch while watching a video. We live in a time where content is being put out at an unheard of pace. Conferences will often put out either some or all of their material after the conference for absolutely free (truly a service to fellow humanzies at large, looking at you StrangeLoop... thank you). This gives us commoners a chance to gain access to well thought out technical discussions about all kinds of things that we normally would never have access to unless we work for employers that find value in sending us to some conferences (and most employers unfortunately do not do so), or we take the initiative and foot the load ourselves.
Having an area to watch things like this is extremely helpful, and I don't mean everyone crowding into one of your fellow colleagues cubicles and squinting to watch it on their tiny laptop monitor. I mean a proper spot with a nice large screen and comfortable seating to relax, eat lunch, enjoy one another's company, and learn.
Lunchtime at the movies, for me, aids in spreading some of the thoughts and things that I may be interested in out to my larger team. I've pulled together some of the places that I look to for snagging a video from below. If you tend to watch vids of stuff from the chatterboxes in our industry, where do you cull them from? I'm not looking for Pluralsight or Udemy types of courses, but more conference or meetup/usergroup types of things.
One of the great things about working with a team of good people (and by good I mean you care about producing useful stuff and helping out your fellow humanzies) is that everyone has been exposed to different things, have differing bases [bey-seez] of knowledge, and hold their own ideas about technology and the world. You may find out about them either through pairing with folks, coming together as a larger team to solve a problem, over coffee, or on a team outing.
Another avenue is over lunch while watching a video. We live in a time where content is being put out at an unheard of pace. Conferences will often put out either some or all of their material after the conference for absolutely free (truly a service to fellow humanzies at large, looking at you StrangeLoop... thank you). This gives us commoners a chance to gain access to well thought out technical discussions about all kinds of things that we normally would never have access to unless we work for employers that find value in sending us to some conferences (and most employers unfortunately do not do so), or we take the initiative and foot the load ourselves.
Having an area to watch things like this is extremely helpful, and I don't mean everyone crowding into one of your fellow colleagues cubicles and squinting to watch it on their tiny laptop monitor. I mean a proper spot with a nice large screen and comfortable seating to relax, eat lunch, enjoy one another's company, and learn.
Lunchtime at the movies, for me, aids in spreading some of the thoughts and things that I may be interested in out to my larger team. I've pulled together some of the places that I look to for snagging a video from below. If you tend to watch vids of stuff from the chatterboxes in our industry, where do you cull them from? I'm not looking for Pluralsight or Udemy types of courses, but more conference or meetup/usergroup types of things.
Sunday, February 21, 2016
What are your favorite podcasts?
Being a husband to my wonderful wife, father of 2 amazing kids, employee of an awesome company, creator of things (like ShopToTrot), someone who is trying to blog more, create more, do more, yada... yada... yada, time can be scarce. One of the tools that I use to keep in touch with what's what in technology land is podcasts.
I usually sneak in a listen on my way into work after I've dropped off my little munchkins at school, which typically amounts to 15 to 20 minutes of geekery. While I typically don't make it through an entire podcast in one sitting, as most run about an hour, I get enough of a fix on my morning drive to keep tuning in the next day. It's just enough to give me something to think about either actively or on one of my many background threads that like to solve things subconsciously for me.
Is there always a direct benefit to my daily grind... no. But it does keep me abreast of techno land in a way that nothing else can. I don't always have time to sit down and read deeply about a subject, and this helps to gain a deeper than surface level understanding on some topics.
Here's what I've been listening to lately:
SE-Radio - This is one that I hit for what I call bigger fish I guess. It's where I'm more likely to run across someone like Linda Rising, someone chatting about CAP theorem, or a good hearted discussion about the GOF 20 years after the initial publication of their book.
The Changelog - This is where I go to get my open source fix and things that might be more on "the edge".
Simple Programmer - This is where I hit for good advice on moving my career forward and personal development (and in all honesty I relate to the guy).
I did a search for "github podcast" and this awesome list turned up from Guilherme Dutra (thanks dude, it's a part of the awesome list of lists). It contains quite a bit and perhaps you can discover something new there.
I've recently started using Overcast to manage and listen to my podcasts, I recommend it. One of the reasons I made the hop was I wanted something that helped in controlling what podcasts actually got pulled down to my phone vs. allow me to stream. Overcast will let you set how long to hold onto a podcast before deleting it... you can always go back and grab it again if you need it. If you decide to use it, be kind and drop the folks that make it a few bucks... nothing in life is free.
This isn't necessarily my complete list or my historical list, but it is the list that's comprised my last 6 months or so. I'm interested to know, if you listen to podcasts, regardless of if they are technology related or not, what are they? Everything I listen to isn't necessarily technology related (although lately they have been), and I would love to know what your tuning in to and why you are tuning in.
I usually sneak in a listen on my way into work after I've dropped off my little munchkins at school, which typically amounts to 15 to 20 minutes of geekery. While I typically don't make it through an entire podcast in one sitting, as most run about an hour, I get enough of a fix on my morning drive to keep tuning in the next day. It's just enough to give me something to think about either actively or on one of my many background threads that like to solve things subconsciously for me.
Is there always a direct benefit to my daily grind... no. But it does keep me abreast of techno land in a way that nothing else can. I don't always have time to sit down and read deeply about a subject, and this helps to gain a deeper than surface level understanding on some topics.
Here's what I've been listening to lately:
SE-Radio - This is one that I hit for what I call bigger fish I guess. It's where I'm more likely to run across someone like Linda Rising, someone chatting about CAP theorem, or a good hearted discussion about the GOF 20 years after the initial publication of their book.
The Changelog - This is where I go to get my open source fix and things that might be more on "the edge".
Simple Programmer - This is where I hit for good advice on moving my career forward and personal development (and in all honesty I relate to the guy).
I did a search for "github podcast" and this awesome list turned up from Guilherme Dutra (thanks dude, it's a part of the awesome list of lists). It contains quite a bit and perhaps you can discover something new there.
I've recently started using Overcast to manage and listen to my podcasts, I recommend it. One of the reasons I made the hop was I wanted something that helped in controlling what podcasts actually got pulled down to my phone vs. allow me to stream. Overcast will let you set how long to hold onto a podcast before deleting it... you can always go back and grab it again if you need it. If you decide to use it, be kind and drop the folks that make it a few bucks... nothing in life is free.
This isn't necessarily my complete list or my historical list, but it is the list that's comprised my last 6 months or so. I'm interested to know, if you listen to podcasts, regardless of if they are technology related or not, what are they? Everything I listen to isn't necessarily technology related (although lately they have been), and I would love to know what your tuning in to and why you are tuning in.
Sunday, February 14, 2016
One Class Per File
I've been using C# as one of my primary languages for the past 6 years where I currently work. Prior to that I was working with Java. One of the immediate differences that I noticed was that it was not uncommon to have multiple public classes in a source file. C# allows it, so why not.
Coming from a Java background I was used to one public class per file, where the filename needed to match the public classname in the file, and for me... I preferred it that way. I felt that it helped to organize the code. Some may say, having multiple classes in a file can aid in readability/discoverability/understandability/insert-an-ability. All true, they can. It can also be harmful in each of those respects as well... all depends.
This week I've discovered a new reason why I prefer one class per file. Changes to classes are more traceable if a class has it's own file. Huhhh?
The reasoning goes like this. If I start out and have a couple of small public classes in a file, then tracking changes doesn't seem too difficult. The problem comes in when the classes grow. Your file will becomes larger and larger, and when you look at the file, there might all of a sudden be too many concepts in the file for you to keep track of. This can especially be the case where you can have a file named a name that has nothing to do with any of the classes inside of it (poor form imo, but to each his own). Some of the classes in the file may be related to the filename, but if sloppiness has crept in (not unheard of) then other classes may not be as closely related to that filename. Different concepts and abstractions may have crept into the file, and you may not realize it for a while. Yuck.
Then one day your in the file and your like, ZOMG, this file is too large and has too many concepts in it, I have to tease it apart. And so you do. You become the boy scout and you tease classes out of it, putting them in their respective files with the respective filenames and namespaces. And when you do this, your original file can in the worst case be empty (remember, the filename doesn't have to match any of the classes, and you just teased all of the classes out). And so you delete it. No problemo dude. And then you commit it and push it up to the remote (because your working in git).
And now, well now all of the history that you had in commit messages is gone for every class that was in the original file. It's not like renaming a file in git. You can always use the `--follow` flag on the current file you have to retrieve the full commit history for that file.
Unless your a good tracker, chances are you're not going to re-discover where those commit messages went for the deleted file. Perhaps you'll never need to. I hope so.
Commit messages are a blessing for both me and my fellow developers because they are in some part a diary of what we were thinking about when we made changes. I've been getting more and more accustomed to making rather large commit messages lately. I'm recording more of the thoughts that I had around the design choices I've used, and perhaps even recording patterns I used in the commit.
The history of changes to a class is important to me. Maybe I've found some religion on this issue, and most probably, I'm going to be more prudent on keeping... one public class per file come Monday.
References:
Brad Abrams - Design Guidelines, Managed code and the .NET Framework
- Source files should contain only one public type, although multiple internal classes are allowed
Coming from a Java background I was used to one public class per file, where the filename needed to match the public classname in the file, and for me... I preferred it that way. I felt that it helped to organize the code. Some may say, having multiple classes in a file can aid in readability/discoverability/understandability/insert-an-ability
This week I've discovered a new reason why I prefer one class per file. Changes to classes are more traceable if a class has it's own file. Huhhh?
The reasoning goes like this. If I start out and have a couple of small public classes in a file, then tracking changes doesn't seem too difficult. The problem comes in when the classes grow. Your file will becomes larger and larger, and when you look at the file, there might all of a sudden be too many concepts in the file for you to keep track of. This can especially be the case where you can have a file named a name that has nothing to do with any of the classes inside of it (poor form imo, but to each his own). Some of the classes in the file may be related to the filename, but if sloppiness has crept in (not unheard of) then other classes may not be as closely related to that filename. Different concepts and abstractions may have crept into the file, and you may not realize it for a while. Yuck.
Then one day your in the file and your like, ZOMG, this file is too large and has too many concepts in it, I have to tease it apart. And so you do. You become the boy scout and you tease classes out of it, putting them in their respective files with the respective filenames and namespaces. And when you do this, your original file can in the worst case be empty (remember, the filename doesn't have to match any of the classes, and you just teased all of the classes out). And so you delete it. No problemo dude. And then you commit it and push it up to the remote (because your working in git).
And now, well now all of the history that you had in commit messages is gone for every class that was in the original file. It's not like renaming a file in git. You can always use the `--follow` flag on the current file you have to retrieve the full commit history for that file.
git log --follow path/to/filename Unless your a good tracker, chances are you're not going to re-discover where those commit messages went for the deleted file. Perhaps you'll never need to. I hope so.
Commit messages are a blessing for both me and my fellow developers because they are in some part a diary of what we were thinking about when we made changes. I've been getting more and more accustomed to making rather large commit messages lately. I'm recording more of the thoughts that I had around the design choices I've used, and perhaps even recording patterns I used in the commit.
The history of changes to a class is important to me. Maybe I've found some religion on this issue, and most probably, I'm going to be more prudent on keeping... one public class per file come Monday.
References:
Brad Abrams - Design Guidelines, Managed code and the .NET Framework
- Source files should contain only one public type, although multiple internal classes are allowed
Friday, November 20, 2015
Monday Night Rituals
Monday nights for me have a ritual on them now. I say now, but in reality they have had a ritual on them for several years now. Several years seems about the right amount of time to actually claim something as a ritual I suppose. It's for sure past the 66 days it takes to formulate a new behavior.
Anyways, the ritual is I meet up online at 10PM Eastern / 7PM Pacific time with a good friend of mine, Dan Gilkerson, and discuss "stuff". Mostly we chat about side projects we are working on, but it can range widely depending on what we've been involving ourselves with and who else is on the call. How do I lay out what this "stuff" is. A list would probably work best.
Anyways, the ritual is I meet up online at 10PM Eastern / 7PM Pacific time with a good friend of mine, Dan Gilkerson, and discuss "stuff". Mostly we chat about side projects we are working on, but it can range widely depending on what we've been involving ourselves with and who else is on the call. How do I lay out what this "stuff" is. A list would probably work best.
- Helpful patterns to use in meteor.js.
- What's a good name for our latest project idea (namecheckr is a fantastic tool to check name availability for this).
- Here's an idea similar to one we've had, and look someone has built a project around it.
- What's the latest thing Dan has learned in his latest hobby.
- What Kickstarter has peaked our interest lately.
- What's the next thing for XYZ side project we are tackling.
- ... A plethora of other things
Meeting later in the evening for me has helped with fitting things together. By 10:00PM we've gone to whatever after school activities are up for the day (soccer/dance/t-ball/kungfu), we've eaten, completed all homework, hung out, taken baths, and gotten the little angles that are my children down for bed. It gives me a good hour to decompress after the kiddos go down to sleep. My rule is to try to be done with the meeting by 11:00PM or 11:30PM at the latest so that I can still get a relatively good nights sleep.
I bring this up to say this. That if there is a side project that you intend to do, outside and beyond what you do in your day job, start with one simple ritual. Our Monday Night ritual is one of a series of rituals that I've put in place to try to make it to that next lilypad in the pond of life for getting some successful side projects flowing. You may ask, are they successful? Is anyone using them? Yes, some are. Not huge successes yet, but enough success to be able to watch people use the systems, which gives us feedback for what's next.
Monday, June 1, 2015
The Grapefruit Buck
I have had the pleasure of discovering The Grapefruit Buck, my drink of choice when I need a serious break from the code. Give it a try, it helps to brink clarity to the world ;)
- A generous portion of ice
- 2 shots Absolute Ruby Red Vodka
- ½ shot St. Germain's Elderflower liqueur
- a splash Campari Bitters
- a splash Lime Juice
- fill the rest with Ginger Beer
- drop a slice of grapefruit on top
Thursday, December 11, 2014
The long race
Finishing a side project takes a tremendous amount of persistence, even if the tooling you use provides a lot for you. Keep going, just keep going, is what I have to routinely say to myself. It's hard though, and requires a lot of deep breaths on my part.
Subscribe to:
Posts (Atom)