Categories: Business and Development
Well, as I sit here at barrio in terminal 2 of the MSP airport I realize just how big of an opportunity I am bring being presented with. Being a full stack dev looking to separate myself from the crowd I found front end development interesting, opinionated, fun, and fulfilling more than other parts. I like to think I bring clarity and simplicity to both code and ui’s through my creations. With all the excitement in the world fueling my passion I could only go so far without supporting casts like my wife, my boss, his boss, her boss and ultimately the CEO of my work and the company as a whole. I want to take this trip to better me, as a developer, as a name, as a person, as a leader, and as a valuable employee. Much is to be learned and hopefully i can sponge it all. Wish me luck!
Tags: development, food.eat, ruby, and ruby on rails
I have been planning, plotting, schema…ing(?) about Food.Eat since my original post. I have made some progress but I have not nailed down exactly how I want to handle user authentication/authorization. Mostly, I think this is due to my choice in the loosely scripted PHP backend. With that knowledge tucked in the back corner of my head I made a desicion this morning based on some information from listening to one of my first podcasts Adventures in Angular I am going to not only learn but also use Ruby on Rails for my backend.
Ruby on Rails is a full stack web application framework that is relatively young by comparison to many languages in use today. It is fast, nearly pseudocode (spoken language-ish).
Similarly to using ruby as a new language on Food.Eat I also made the decision to go with angular 1.3.X for performance reasons and am also following John Papa’s Styleguide which, in my opinion, made my angular code much easier to read (Example).
If you would like to see any of the workings as I move forward, please, star, fork, help out, or just think “huh, Matt types things and I have no idea what they mean or he is talking about”.
P.S. Sneak peek
Recently I decided I was going to look into a simple app that I wanted to build. The app for a first pass will be a simple angular/slim php backed app that will use a smartphone’s camera capabilities. The idea behind the application would be that as your day goes on you want to track all the things you eat. We all know the jig, get out the phone, boot an app, enter some arbitrary feeling information on your food you are about to eat. Well that is where I am going to attempt to differentiate, I want just a simple snap-shot picture. Take a picture and chow on! Heck, share it on instagram anyway, why not upload it to my server too? That’s it. The point of it is that each day you can see the amount and what you consumed. I believe the barrierless feel of it will make it easier to use than many “health” tracking apps.
From this point in the game I am architecting how my database is structured and planning out the implementation details. I am most likely going to host the code in a public repo on github because I feel this idea isn’t revolutionary, just unique. The easier I am able to make it the better off I will be in the long run. Of course, I will be withholding specific pieces of information like database passwords and adsense pieces.
Long time, no talk, internet! Recently, we have been extremely busy at work getting market ready launch of a new product ‘redeem.’ Leaving me very little time to write about anything (in a blog sense, plenty of coding). I have plenty to say and very limited time to say it in.
1) Google api v1/2 shut down on the 17th. I inherited a site dev for a nation wide in home computer repair company. It is a bit on the academic side of structure and code but it works. I have since converted much of it to PDO (php) and angular. Well there was also a framework living in the depths, Zend, which internally uses(d) Google api v2. See the tie back now? 48, grueling, hours later the site now uses Google api v3 in native php.
2) I have stepped into a role as a go to front end dev in angular, js and css/less. Which is more about teaching and less about coding, meaning I should NOT forgo “useless” Jasmine tests I did. Market ready, as I mentioned is this release. Code freeze is today. 20 units over our average and we made it. Now bug fun. Hopefully I will be able to take a breath of this harsh early winter Minnesota had served up.
Sorry for the lack of sweet code. I will follow-up shortly with a blur model update directive in angular when I get a minute, not on my phone, to write a party.
Almost forgot! I have listened to a podcast that I have enjoyed, adventures in angular, if you haven’t heard of it, check it out, good information to be had.
Until next time,
Categories: Business, Development, and Web
After quite some time on the same theme I decided it was time to update. The old theme had some severe limitations in post style, ad additions, analytics, headers, footers. You name it, it was a problem. This theme is based of “Spacious” which i have, so far, found quite easy to work with. I haven’t found anything too out of the ordinary with it so far and everything seems to be working as expected.
I am using a twitter and a github widget on the front page as well as a custom theme widget for the front page layout. The rest of the blog is mostly as you would expect it to be, blogy.
Categories: Business and Development
The other day I was pinged by a professor from my college about a potential opportunity to give back to the community who has nurtured my technical growth. She introduced me to two individuals who are growing a newer program in minnesota: Technovation Challenge. This challenge is aimed at middle and high school females in an effort to give them opportunity to show off their technical savvy and a chance to learn a new skill. We will be using MIT’s App Inventor which is a drag an drop, block based programming language which lowers the barrier to entry for youth/adults in general. I am very excited about being a part of this program and helping Minnesota continue becoming a technology hub in the midwest.
Categories: Business and Development
Tags: coders, ethics, programmers, and psychology
So, today, as most days, during compilation or time I take to rest my brain from strain I was reading through some of the G+ posts on development, technologies, and programming and came across this post. It is an excerpt from Jerry Weinberg’s book The Psychology of Computer Programming.
1) Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2) You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
3) No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
4) Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5) Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
6) The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7) The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
8) Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.
9) Don’t be “the guy in the room.” Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10) Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
The most amazing part of all of this, in my opinion, is that this book was written in 1971. Remember that year? I don’t, wasn’t even alive yet, but do you know who does? Intel. Intel introduced the first microprocessor November 17th, 1971, the Intel 4004. Apple hadn’t released a computer yet.
Keep the commandments in mind in your work and I promise that you will be a better developer and be of more worth to everyone around you.
Tags: development, interview, social skills, and software engineer
Today is the first day in my career at Vecna that I get to give an interview.
I have given interviews in the past, hiring for my earlier companies, ByME (all technical employees) and Illume (the sole other engineer). But I have never done anything in this respect here at Vecna. I view this as a great opportunity to further my skill set as a leader, innovator, and a resource for myself and my employer. I have given great thought on questions I will ask and things I want to carry out in getting to know the people that I will talk with. I have to conclude that, considering they are MIT undergrads, I can put a solid foothold on the fact that they will have basic understanding of OOP (Object Oriented Programming) and it’s patterns. However, I can NOT necessarily say that these people will make good coworkers in our environment.
Who doesn’t want to work with someone who they enjoy talking to, someone who they would like to bounce an idea off (work related or otherwise) and see what comes back. Some of my favorite people with whom I have had the pleasure to work with are not just brilliant minds in software engineering but also; moonlighting at a homebrew emporium, an avid small skit actor, a car enthusiast, and a lover of all things scotch. These people peek interests that I, at one point or another, have interested in or admire.
I want to give off perception of respect and openness to the person so they will feel that they can truly share what they love in their life.
There is much that The College of St. Scholastica taught me but the thing I value above any lessons taught by my teachers is that of the Computer Club. I learned how to lead, to be a well-rounded person, to have fun. This is very important and I think a lot of the technical world forgets how to do it some time. If you get the chance to bring some fun into your workplace in some form DO IT!
Categories: Business and Development
As many of us do as software developers/engineers/hackers I have been to, answered and asked my share of questions on stackoverflow in my career. They also now have an invite careers section of their site. I joined recently and have since completed my profile to a point where they see fit to grant me some invites.
Not really much else to say but: Accept Careers 2.0 invite =)
Staying in touch with old coworkers and employers
A few days back I was contacted by an old coworker that I used to work with at a company who, since my departure, had taken a turn for the worse and closed their doors. Well, at least that is the last I had heard. One of the founding investors was trying to revive the idea/company and wanted to bring me back on as a consultant. I was thrilled at the idea to help out and said I would help in any way I could.
Keep Any Documentation that is Legally available to you
During this phone conversation I have/was referring to many of the documents that I had written during my tenure at the company to remind myself of the ideas and the processes that I was building. These documents have proven to be invaluble to both myself and the now newly running company
- Resume boosters: what company will look poorly on you helping out a past employer (no need to mention compensation)
- References: the better info you share the better they will think about you later, even if it is just a bar talk with someone you will some day meet…
- Care: where you work and who you work for should matter to you even AFTER you work there
- Money: most of the time they will pay you well