Wednesday, December 22, 2010

2010 Rundown by Jaime Bueza

2010 has been a great year. Here's a rundown of the things I did.

* Gave an introductory talk on NodeJS to the front-end team at Blast Radius
* Explored test automation with Selenium and NodeJS using SodaJS + Kyuri
* Created a free cross-platform app built on PhoneGap (CoffeeCheck.In)
** Iteration 1 Video
** Iteration 2 Video
* Contributed to the HTML5Boilerplate (Pull Request 209)
* Learned NodeJS (Express, npm, etc)
* Learned MongoDB
* Learned CouchDB
* Read "The Fifth Discipline" by Peter Senge
* Read "Getting Things Done" by David Allen
* Read "Rework" by Jason Fried
* Read "The Mythical Man-Month" by Frederick Brooks
* Read "Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister
* Read "The Tipping Point" by Malcolm Gladwell
* Built a NodeJS Pokemon demo with HTML5/CSS3/JS/WebSockets
* Built a jQuery Omniture plugin
* Released a more sane way of doing IE6 Warning with localization
* Released Blast Mojo Framework: Episode 2 tutorial
* Released Blast Mojo Framework: Episode 3 tutorial
* Released Blast Mojo Framework: Episode 4 tutorial
* Contributed to Blast Mojo Lite, scalable JS microframework on top of jQuery
* Half constructed a World of Warcraft addon "Ninjalist" using Lua
* Quit World of Warcraft!

Upcoming goals for the new year 2011:

* Write and contribute more open source software
* Build some really kick ass test automation software
* Do more python projects (django)
* Play with more Tornado, Scala, Erlang
* Play with more Kinect hacks using libusb and NodeJS (Minority report h4x)
* Build more Android apps
* Give a talk on SodaJS to the technology team at Blast Radius
* Give a talk on WebSockets (real time apps) to the tech and front-end teams at Blast Radius
* Give a talk on NodeJS to the technology teams at Blast Radius
* Give a talk on regressive enhancement/polyfilling techniques to Blast Radius
* Give a talk on tips with SASS, such as, easy minification and deployment
* Give a talk on RequireJS or HeadJS to the teams at Blast Radius
* Give a talk on data-uri (base64encoding images) to reduce http requests with strategies for cross-browser functionality at Blast Radius
* Give a talk on how to use Git at Blast Radius
* Start company hackathons to improve mental agility for developers?

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Monday, December 20, 2010

How to push forward as a large software development corporation

The Art of War has taught us that when a skilled general decides on a strategy to execute on, they either move quickly, or stay in a position that yields a tactical advantage over his/her enemy. Incidentally, we can apply the same concept in corporate culture. If you take a second to disconnect yourself from your environment, zoom out to a birds eye view, you'll realize how really slow your team is progressing in comparison to the rest of the world.

Naturally, human beings can only see what is in front of them and they need to be constantly reminded of where they are and how they're progressing within their environment. That said, dispelling the blindness of corporate software development is like fighting against an enemy on his own turf and consistently having a positional disadvantage.

The question we keep trying to explore is: what can we use as leverage against such a tough and determined enemy? This is a vicious opponent that not only flattens the spirits of your teammates but paralyzes your abilities to think quickly, act quickly, and move quickly.

If your corporate culture finds itself in quicksand, take a moment to really assess the situation: as time goes by, you're sinking to your inevitable death. In order to really get around your slow and painful demise, you need to use leverage. The answer I believe is in the tools. Tools provide leverage. Much like a lever, you're able to use a minimal amount of effort but exert an incredible amount of force. As a software developer, my job is to write programs that are supposed to be useful. I've decided to generalize the role of a software developer because we are essentially builders, designers, crafters, wizards of the arcane, and automaters.

Examples of leverage are

- a tool that provides an intuitive user interface that all masteries (project management, engineers, and designers) of your team can use for software defects. (bug tracker)
- a tool that provides easier visualization of software requirements (diagramming software)
- a tool that provides sanity and health checks on your software (automation testing)
- a tool that provides a hub for knowledge sharing (wiki)

Since these examples are just tools, we must also understand that there is no such thing as a silver bullet. In some corporations, these tools may be used incorrectly, which wouldn't benefit the company at all; however, if you're able to maximize the potential of these tools and build a shared vision with your teammates, you'll find your company slowly dispelling its entanglements and pushing forward.


Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Wednesday, December 8, 2010

Ideas are useless without proper execution

So stop saying you have ideas and start executing.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Sunday, December 5, 2010

Advertising companies need to catch up with how the Web platform is expanding. Location-based services is the next natural step

Mobile app spendings are consistently increasing as we push forward into the future. Incidentally, there are advertising agencies that are still stuck on desktop customer experiences. The future is going mobile and I feel like Apple is the only company that is scaling with the growth of Mobile advertising with iAd.

The biggest trending mobile web services at the moment are location-based. FourSquare and Facebook Places aim to drive local advertisement throughput by being able to notify users which locations are hot and which are not. From fine dining to parties--location-based services will shape our reality by changing our views on our local environments. A simple use-case would be if I were in the area and one of my Facebook friends was at nearby Coffee Shop that I've never gone to before. I would be inclined to meet up with my friend and grab a coffee. Since I've never been there before, I would be rewarded with a badge or an achievement (FourSquare).

A simple reward system is so addictive and I believe that rewarding users will be a primary piece of functionality in most social networks in the future.

The next question is, "will there be a bubble burst like in year 2000?". My thoughts are "no" for a couple of reasons. In 1999, 99% of starters didn't have profitable business models and the Web as a platform wasn't viable for the business models they wanted to exercise. Today, we have smart phones that have fully capable web browsers and more users on the internet on massive social networks like Facebook, Twitter, Yahoo, and Google. Since most people are connected in someway to a larger network, the rise of 3rd party APIs came to be as a way of "connecting the different universes". Think of it as a way of achieving warp speeds and getting to different parts of the universe--This eventually led to the construction of useful mashups which would consume these APIs into centralized systems.

What does this mean to the user? As technology constantly improves and design becomes more innovative with touch and spatial interfaces, we'll see a rise of newer strategies for targeted, location-based advertising. Context is always a huge win when it comes to online advertising. With location-based social networking, users will have full confidence in the decisions (s)he want to make because their friends are doing it. It's not something that you're forced into doing like TV and Flash video advertisements.

Cheers,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Saturday, December 4, 2010

Building teams based on passion

After being in a meeting on how to increase team effectiveness and increase the quality of the products we're trying to build, I thought of the process of building teams based on a common passion.

Diving deeper, have you ever met a creative person that loved designing social networks? What about a designer that loved creating interfaces on Mobile platforms? Have you ever met a developer that loved building software that connects people? Why is it that teams in the agency realm with multiple disciplines can't grab a group of people who have a common passion. This is totally different from basing it on "skill set". It's about what they love to build. For example, my skill set ranges from backend (multiple databases, multiple integration languages, localization) to frontend (html, css, js) on different platforms like web and mobile; however, I love building social networks on mobile platforms and how you can integrate with different 3rd party services like Flickr, Facebook, Google, and Foursquare. I strongly believe that the world is moving towards Mobile and some form of secure way of sharing data between different services.

In our current ways of doing things, employees (designer/developer/project manager/quality assurance) are just "resources"--they're thrown around on to different projects with barely any context. Context switching is so expensive--ramp up time, meetings, discovery, and rebuilding a shared vision.

If the overall goal is to secure projects so we can gain revenue (what comes in is what comes out) without knowing exactly what we're trying to build then the designers and developers should have full rights to opt-out of the project. As in, they shouldn't have to build something they're not passionate about. What does the company need to do then? Hire contractors. I'm lucky to have landed a few projects that I've been quite passionate about but I've also had to deliver projects which I totally wished I wasn't associated with. The quality is quite obvious.

My only suggestion to companies that are paralyzed in this state is to try and interview your designers and developers. Figure out what they really love making. Ultimately, humans intrinsically love to build things on their own--why not leverage this aspect of human behaviour to build better software?

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Wednesday, November 24, 2010

What was your first programming job and were you qualified?

My tale starts when I went in for a job interview at the Vancouver Film School. The position I was applying for was "Intermediate Developer" -- Something I was completely unqualified for. The role of an "Intermediate Developer" would be to write internal applications on a LAMP stack and support the Senior Database Developer with any database scripts for different departments (admissions, human resources, accounting, etc). My first interview was a generic HR meeting. Incidentally, I studied everything about the different programs of VFS prior to meeting with HR and she asked me, "so what do you know about Vancouver Film School?" -- Boom. I recited everything that was on Wikipedia. I even listed out all 10+ programs from acting to game design to entertainment business management. I felt like I completely dominated that interview.

That very day while I was on my way back to BCIT to finish off a project, I was called in for another interview the following day. This was with the Senior Database Developer--in other words, my future boss and mentor. The interview was held at the VFS Cafe (392 W. Hastings) and it was a super casual conversation. He asked about what projects I did at school, what my favourite text editor was, and technical questions about MySQL that I didn't know but I gave it a shot. I remember questions regarding JOINs and subqueries--Things I learned at BCIT in an Oracle course. While on my way to the bus loop (130) to go back to BCIT, I got a call from HR with an offer. I accepted it.

As an Intermediate Developer, I ended up doing the following:
- Being introduced to Mac OS X's awesomeness (I was a PC guy)
- Being super comfortable with terminal, ssh, and MySQL command-line
- Exploring the business value of better user experience (ajax, animation, rich components)
- Optimizing sql queries
- Importing/exporting data between different environments
- Developing internal web applications that help the business users with their day-to-day needs (tracking systems, inventory systems)

5 years ago, the technology scene was basically "Ruby on Rails vs PHP". Along with Ruby on Rails came PrototypeJS and Scriptaculous for making "Web 2.0" sites. There was no jQuery. MooTools and Dojo had no documentation and were in their infancy. The only solid UI library with sufficient documentation was YUI. That said, I took on the initiative of implementing rich user interface components (autocomplete, data tables, modal dialogs, drag drop) on existing internal web applications. Student searches were far more productive and intuitive for the business users. After doing several upgrades on the user interface, I found myself transitioning into a front-end developer instead of working on database-related work. I was able to do it but my passion for interface development was growing.

After a year of working at VFS, I asked myself, "we have all these internal systems on different locations, it's gotta be painful for the business users, why not just create a system that integrates all of them?" After the idea sparked--a web application of drag-drop modules (Web dashboard) that are mini-views into different systems. This dashboard would be fully customizable, as in, you would be able to add/remove specific modules from your dashboard and add cooler ones, such as, a weather module or a YouTube search module. Not only that, it was fully integrated with the web mail client. Ultimately, this system was the one stop where employees could go for their daily tasks: student searches, employee searches, cafe menus, support tickets, upcoming events, bug tracking, google maps, google search. The system was setup to be able to scale out with new modules. This seems like an easy-mode system to develop nowadays but 5 years ago this would be considered "heroism". iGoogle wasn't even around and the only thing that resembled it was Pageflakes or Netvibes.

After two months of development, it was officially launched internally to the business users and everyone loved it. There was widespread adoption because it made their work lives easier.

After a year and a half of employment at Vancouver Film School, I soon realized that I didn't want to optimize SQL queries, do backups, or import/export data between different environments.

I wanted to do front-end development.

To answer the question, "was I qualified?"--The answer is "no". I was a kid straight out of BCIT with only general programming knowledge. I wasn't equipped with the mental agility to solve "real world business problems". It was one hell of a ride though -- The feeling of knowing that your work has business value and your users are happy!

Things that were awkward at that work place:
- No version control for all internal systems (svn/git)
- No continuous integration
- Tightly bound code to several God objects
- No functional specifications
- No API documentation
- No ORM for a massively complex universe of internal systems

What was your first programming job and were you qualified?

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Tuesday, November 23, 2010

Unionization for Developers and Designers

There was a time in the past where I actually thought developers and designers would benefit from unionization. I realize now that it would shape a devastating reality to the overall advances of technology and design. Unionization would paralyze our ability to innovate because the level of protectionism inherent in unions encourages laziness.

By looking at different disciplines, such as, carpentry and construction, we can observe that there hasn't been any real innovation in toolsets. Carpenters still do not have any robust tools that'll make their jobs 100x more convenient. I compare that manual labour to a programmer writing in binary just to build an eCommerce site. It is puzzling how other technology sectors have little to no progression. Another example is economic airline technology--20 years ago we had super sonic jets and now we're stuck with slower airplanes. How do they fix this problem? They improve the fuel efficiency in the engines. Aircraft technology needs another Howard Hughes--someone who can really push the industry in the right direction and really make lives better. Without Howard Hughes' achievements, we would never have had commercial flight.

In software, there are many heroes that have Howard Hughes' determination to prevail: Steve Jobs, Mark Zuckerberg, and Bill Gates. While Steve Jobs has been leading the efforts in consumer software and hardware (computing and mobile), Mark Zuckerberg has been leading the efforts in social networking. Facebook has revolutionized the way humans interact with each other by allowing people to build new relationships, rekindle old relationships, and share life's timeless memories through videos, photos, and status updates.

One of the primary reasons I design and develop software is because the environment changes constantly. It's an evolving ecosystem to be in. Problems are surfaced and solutions are executed against those problems at different angles. It's fast-paced.

Imagine a world where developers could work 8 hour days and be confident about his unfinished/untested work. What about his teammates? Don't they depend on his code being feature complete? Nothing would ever get done because of the level of protection unions provide people -- It's a shield for the lazy.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Monday, November 15, 2010

Leadership

Words by Lieutenant General Hal Moore:

There are four principles in leaders conduct in battle. First is three strikes and you're not out. There's 2 things a leader can do, either contaminate his environment the unit with his attitude and actions or he can inspire confidence. He must be visible on the battlefield. He must be in the battle. Self-confident, positive attitude, must exhibit his determination to prevail no matter what the odds or how desperate the situation. Must have and display the will to win by his actions, his words, tone of his voice on the radio and face-to-face, his appearance, his demeanour, his countenance, The look in his eyes, he must remain calm and cool--no fear. He must ignore the noise, the dust, smoke, explosions, screams of the wounded, the yells--the dead laying around him, that is all normal. Must never give off any hint or evidence that he is uncertain of a positive outcome even in the most desperate situations. Again, the principle that must be driven into your head and your head's of your men is 3 strikes and you're not out.

And the corollary principle which is interactive with one is there is always one more thing that you can do to influence any situation in your favour, and after that one more thing, and after that one more thing, etc.

In battle, I periodically detach myself mentally for a few seconds from the noise, the screams of the wounded, the explosions, the yelling, the smoke and the dust and the intensity of it all and ask myself: what am I doing that I should not be doing and what I am not doing what I should be doing to influence the situation in my favour?

The third principle is when there's nothing wrong, there's nothing wrong except there's nothing wrong. That's exactly when a leader must be most deliberant.

Finally number four, trust your instincts. In critical, fast moving battlefield situations, instincts and intuition amount to an instant estimate of the situation. Your instincts are the product of your education, your reading, your personality, and your experience--trust your instincts. When seconds count, instincts and decisiveness come into play. In quick developing situations the leader must act fast impart confidence around him. He must not second-guess the decision--make it happen. In the process, he cannot stand slack-job when he is hit with the unexpected. He must face up to the facts, deal with it, and move on.

Inspirational words for team leaders on any project.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Sunday, November 14, 2010

Why Boxing Is In Decline And Solutions To Increase Viewership

After watching tonight's fight between Manny Pacquiao and Antonio Margarito, I decided to explore why boxers are able to duck out of fights (Mayweather). The boxing federation, as a company, has it structured all incorrectly. In all honesty, boxing is in a state of decline and the only real way to re-energize the fans and really get some growth in the boxing community would be to revise the fight policies.

In the UFC, fighters are employees. The organization constitutes regular fight schedules so that the fans of the sport can be assured consistent fights (something to reliably look forward to). Conversely, in the sport of boxing, fighters are treated as separate companies where they're able to decline fights and employ an army of lawyers to ensure they win negotiations.

While Floyd Mayweather is able to stir up the declining boxing fans with his ridiculous galavanting and trolling in the short term--the long term integrity of boxing as a sport suffers. Slowly but surely fighters with dishonourable, immature behaviour will transform the sport of boxing into a WWE (World Wrestling Entertainment). Incidentally, a sport has always been about the people that are passionate about the sport.

Moving forward, I believe that if they revised the fight policies as so:
  • Fighters should be treated as employees, not separate corporations. There shouldn't be 'negotiations' that involve lawyers for an event.
  • Fighters should not be able to choose their opponents. Boxing allows boxers to hand-pick their opponants to inflate their win records.
  • Fighters should be disciplined for racial discrimination as an employee of the World Boxing Federation.
  • Regular fight schedules so that boxing analysts have better data and fans are consistently given the entertainment that they want.
  • Standardize Olympic-style testing to prevent fighters from 'juicing up' (steroid usage).
  • Reduce from 12-rounds to 8-rounds to spark more action.
  • Reduce the number of weight divisions to match UFC-style weight divisions. There are far too many weight divisions in boxing--this would increase the pool of fighters competing for championship titles.
  • Change point scale to be binary (0 or 1) instead of out of 10 from each judge for simplicity.
  • Employ stricter referees for stoppages. If the fighter has a closed eye (swollen), the fight needs to stop ASAP for their own health safety. It's a sport, not a murder scene.

With these revisions, boxing could theoretically become more action-packed, competitive, and structured in a way that helps the boxing community's growth and increase global viewership.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Has Ajaxian Gone Down Hill?

Recently, Ben and Dion (the main guys who started Ajaxian) have left Ajaxian's helm to concentrate on other projects. One thing I've noticed is that they've reduced the frequency of posts to about three times per week. Prior to Ben and Dion leaving, there were sometimes 2 posts per day. Furthermore, since the articles on Ajaxian aren't that interesting, I've gone ahead and subscribed to Dion Almaer on twitter. Dion posts about 10 tweets a day on average with really interesting works out there in regards to front-end development.

Twitter is the #1 source for technology and design trends. I barely even open reader.google.com anymore as 140 character tweets can be more informative than walls of text.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Starbucks, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications, and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Wednesday, November 3, 2010

Job Hunting Tips for New Developers Out of University

Open Source projects on your resume are more important than your co-op or education. I've seen brilliant developers that shatter walls of constraints by being strictly committed to the vision of the project. If there was ever an issue that constrained the team's ability to move forward, there was always that developer hero that would step up to the plate and do what he could to resolve the issue. These types of developers don't play by the rules of the game. They change the game.

Software development companies don't want drones. Drones are people who have jumped through the hoops, ran the courses, and are ready to get paid. Drones aren't creative, confident, or committed. Once a company starts to accumulate too many drone programmers, your company starts to grow "corporate arthritis". Corporate arthritis paralyzes your company's ability to deliver your products efficiently with a degree of quality and reduces your company's ability to keep your customers happy.

The first thing a technical hiring manager will do is Google your name. Then, he or she will try to figure out what your Github is. By looking at how many pull requests / tests / gists / repositories you have, we're able to discern the following characteristics:

- How you write your code
- How you inspire your teammates through your ideas and participation
- Why you make certain technical decisions in your projects
- Why specific decisions need commitment from your teammates. Are you able to get commitment out of your teammates on volunteer software development?
- Can you really convince your teammates that your technical decisions steers the team in the direction that best suits the teams' needs?
- How committed and passionate you are about your discipline
- Do you act as a mentor to your teammates?

Since open source software development is solely based on building a shared vision and aligning everyone's personal masteries (design, development, quality assurance, technical writing), you're essentially putting yourself as a developer on the map for smart companies to hire you. There's nothing more important to a company than hiring heroes that really understand the meaning of shared vision, commitment, dedication, hard work, creativity, inspiration, and mentorship.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Sunday, October 31, 2010

Distributed Development / Divorced Software Development

In an attempt to dispel the level of optimism in distributed teams: I'd like to negatively state that divorcing your team like this is the worst way to achieve team efficiency and sustain a high level of quality in your products. None the less, it still happens project to project. I've bounced back and forth between teams where we've stuck in pods (all in one common area) and some where I'm dealing with teammates in a different continent. Sadly, most of the projects that have somehow dwindled down the path of hiring cross continent resources have been the most stressful.

It's not the people that cause problems. As a matter of fact, the team is usually composed of wonderfully talented and smart people -- It's the ineffective communication channels that get incorporated into the delivery process that ultimately divorces team/client expectations.

My primary concern about distributed teams is that upper management fails to see the overall picture of software delivery. Developing software that will indubitably be shipped out to users is not like building toys and shipping it out to kids. Software isn't' built in factories--it's an evolutionary product that empowers your users. Furthermore, there is this imagery that is seeded into the minds of upper management of a programmer building doorknobs (components) that go into doors (web application) and get put into houses (infrastructure/platform). Negatively, we face these issues because of upper management's idea of "how software is shipped to real world users" is hazed and often imagined as a crew of factory workers in a line creating door knobs. On the whole, this stigma isn't exactly targeted to just programmers but to anyone on the production team, such as, designers and quality assurance.

In order to build great software for your users, your team should have a realistic picture and shared vision of how their loyal customers are going to use it. Distributed development--I mean, divorced development not only blinds some of your team members but painfully discourages any sort of effective participation to improve the product. If you hired a programmer from China when your team is in New York, suddenly, he thinks of a great idea of how to make a particular feature more convenient to the user, how is he supposed to communicate this to the team? He has several ineffective ways:

1) Email (which everyone can easily ignore)
2) Calling into scrums/meetings (which is completely useless if people don't document it)
3) Phone call to the lead developer (which everyone can easily ignore as well)

I'm not bashing the fact that the developer is from another part of the world--I am bashing companies with an upper management that enforces such ridiculous team compositions that essentially paralyzes your ability to build great products. I feel sorry for teammates that are far from the core team (design, development, and quality assurance) when they want to participate in the improvement of their delivery but can't due to their proximity and the limiting factors that snare their ability to communicate effectively. Ultimately, team compositions using distributed development practices encourages and amplifies corporate learning disabilities, such as:

1) I Am My Position
2) The Enemy Is Out There

Business has always been about relationships and communication. Indeed, your company can save millions of dollars in development by outsourcing but if you do decide to use this software delivery strategy, then keep constantly inspecting the level of quality in your product line. Upper management will always have a level of blindness to the quality of their product and will always see how much upfront costs they can save if they indoctrinate distributed development processes. If your management team doesn't know how to use the product that you're trying to build, they will never really have the sense of how great the product is for their users as a human being.



Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Wednesday, October 27, 2010

What If

Have you ever asked yourself "what if" when you reach a point in your life where you could've acted on an opportunity? I've been an evangelist of the following quote: "you miss 100% of your shots you don't take". After having this ingrained in my mind for so long, I've come to realize that I am almost always disappointed with myself. Every opportunity I take advantage of, I'm always disappointed--It's like I constantly become blinded: I look at the situation negatively and see how I could've done things better. I feel like a plethora of opportunities lead to an infinite loop of disappointments.

Do I need to dispel my blindness and take the time to cherish the small victories in life? or learn to let things go when mistakes happen? Do I need to stop consistently blaming myself for anything that goes wrong in life? Do I need to sink back down to reality and accept the fact that "I can't always be the hero"?

An endless list of conundrums.

I've always been an independent person with full confidence in my ability to get things done. I put an endless amount of faith in my teammates and I'm righteous about "if you're unhappy, it's because you let yourself become unhappy". Even after so many disappointments, I feel like it's my duty in life to hold on to my humanized values, intuitive sense of honesty, and truthfulness.


Regards,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Tuesday, October 26, 2010

Mentors

In my life quest to figure out the deeper arcanes of social dynamics and emotional intelligence--I've taken notes on patterns of behaviour and characteristics in most great leaders of our time. Frequently, I hear the phrase, "person of integrity" being used to describe leaders.

What does it mean to be a person of integrity?

Wikipedia has the following definition:

Integrity is a concept of consistency of actions, values, methods, measures, principles, expectations and outcomes. In western ethics, integrity is regarded as the quality of having an intuitive sense of honesty and truthfulness in regard to the motivations for one's actions.

Reflecting on my own career--I've been very fortunate to have been led by great individuals that exhibit the level of integrity that Wikipedia describes. In all honesty, my leaders have always been great mentors: they've taught me how to react to situations, how to be as technical as I am today, and how to communicate effectively with other disciplines on my teams. Without such amazing and disciplined mentors, I wouldn't be where I am today and I'm extremely grateful for that.

Mentors don't exactly need to show exactly how certain technical things can be done. Mentors essentially setup a mental framework to create a disciplined thinker. For example, Freddy Roach is Manny Pacquiao's mentor and boxing coach. Freddy certainly can't box at the technical level that Manny can; however, Freddy Roach setups a disciplined approach to thinking: hard work, dedication, sacrifice and most of all "never giving up". By ensuring that Manny's mind is mentally conditioned, he is able to push himself beyond any human limits and be the champion he truly is (best pound for pound fighter in 7 different weight divisions).

Day by day, I constantly strive to push myself beyond my boundaries: learning new things, putting strategies to practice, and improving team vision/learning. Core characteristics, such as, integrity, dedication, courage, never giving up, and sacrifice are all things that I've inherited from my mentors.

In the future, I will achieve my life goal: to be a disciplined mentor for my own teammates just like the heroes that mentored me in the past and perhaps one day I can hopefully make them proud.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Saturday, October 23, 2010

Adding and deleting git tags

Adding a git tag

Common Case:

Johnny is the developer on a project that is about to go-live. Their codebase has passed all unit tests and functional/behavioural tests from QA. Before going live, he needs to tag the current revision so that his whole team can easily backtrack and possibly fix any last minute bugs before launch but also make it so that his team can also keep pushing code to the master branch.

Create the tag:
$ git tag -a v1.0.0 -m "2010-10-10 Production-Ready"

Double check which tag was created:
$ git describe --tags

Push tags to your repository
$ git push --tags

Deleting a git tag

Common Case:

Johnny accidentally created a tag called "v1.9.0" instead of "v1.0.0". He needs to simply delete this tag so it doesn't confuse other developers.

Delete the tag
$ git tag -d v1.9.0
Push the deletion of the tag to your repository
$ git push origin :refs/tags/v1.9.0


Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Thursday, October 21, 2010

Why We Still Need Heroes

History has proven time and time again that the world needs heroes. People who are helpful, selfless and dedicate themselves to a cause--a high level initiative. In the realm of software delivery, where you have to ship a product on a tight deadline, you often face burnouts and frustrations--a seemingly impossible uphill battle. That's why you call on your heroes...

Horatio Hornblower was a British admiral full of integrity, courage, and intelligence. He fully understood the potential and limitations of his team. Without any hesitation, he answered Britain's heroic calling to engage Napoleon head on.

While waiting at his Mediterranean rendezvous point for the rest of his squadron—and its commander—to arrive, he carries out a series of raids against the French along the south coast of Spain. He learns that a French squadron of four ships of the line is loose, having slipped the blockade. He decides that his duty requires that he fight at one-to-four odds to prevent them from entering a well-protected harbour.
- "Horatio Hornblower" Wikipedia

When heroes answer the call of duty, they are compelled to go into battle with the odds stacked against them. His crew had a choice of evacuating back to England but they followed him into battle because Horatio led them: Horatio knew how to encourage his teammates--Horatio knew how to empower his teammates--Horatio could dispel the fear in his crew and transform them into valorous soldiers by crystallizing a shared vision.

In our current projects, we face the same types of situations--sometimes you're thrown into a situation where you can make a difference. In more recent times, Bob Fitch is Blizzard Entertainment's lead programmer. When everyone hated the original Starcraft because it looked like a reskin of Warcraft II, he completely rewrote the game engine within a short period of time. People loved the new result. Starcraft went on to become the most popular eSport in South Korea. South Korea has 2-3 full time running eSports channels dedicated to Starcraft alone.

If you have a lead with that level of integrity, righteousness, courage, and dedication--more people will start to follow in their footsteps. Generally, they want to change the scene and improve things for the better. Furthermore, Blizzard Entertainment has a proven track record because they are a legion of heroes.

Software companies of today never really encourage their "resources" (a foul word for a person working at an agency) to break through walls and voice out their opinions. Incidentally, corporate software development is paralyzed with the learning disability known as "I AM MY POSITION".

You have the ability to punch through walls--you just don't know it until you've tried it. Your actions shape you and your team's reality--you're important to the team. Fill multiple roles (break out of your position), change things to improve your team's shared vision, and eventually, you'll be the hero.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Sunday, October 10, 2010

Understanding Your Team

Have you ever been put on a team that is so brilliant and talented and somehow the project is frustrating to deliver? I've come to realize that when working with a team of great people, there needs to be a level of transparency and level of understanding of what we're trying to build as a whole. In the agency realm, typically you'll have 4 disciplines working together to ship a website:

1) Design (Creative)
2) Development (Frontend and backend)
3) Client Services (Project manager)
4) Quality Assurance

My evolved thinking has brought me to the conclusion that there can't be such a thing as blame. Understanding the delivery as a whole will help dispel the shackles of each discipline. Furthermore, each member of a discipline should fully understand how much of an impact their decisions will make on another part of the system. For example, a designer can choose to break consistency by readjusting the website's grid on a particular page. This would have a negative impact on the development team as most of the time grids are set up at the start and they stay consistent throughout the whole website (column widths). That said, it isn't the designer's fault at all--he/she was just doing their job with poorly written requirements. It could've been that the developers didn't voice that out to the designer--that they're pretty much married to a specific grid format.

Another example is how client services could oversell on a feature that could mean 12hours of design work and 40 hours of development effort. If the client services person knew about how much damage that would cause to the timeline, he/she wouldn't have proposed it to the client. As another example, typically technology platforms for websites can't react quickly to client feedback or design changes. We have very simple tools nowadays to help speed up the approval process from clients, such as, Adobe Photoshop; however, since we ultimately need to ship a website as a whole, even if one part of the system speeds up, the platform itself takes time to catch up. This is called backlog.

Working together doesn't just mean sitting together, or joining scrums--It means learning together. If we learn from each other, learn about our disciplines, learn how each discipline affects another, we can be far more efficient because we'll fully understand our own limitations as a team.

Ultimately, much like the beer game, the problem isn't the process or the system...it is actually "us". We fail to understand each other and how each of our disciplines can have a negative impact on each other based on the decisions we make.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Monday, October 4, 2010

Random Thought at 1am: Treating People Like Human Beings

I've changed a lot since I came out of post secondary.

When I first came out of post secondary (BCIT), I was a driven, dedicated, and passionate knowledge-hungry kid that wanted to tackle each and every challenge on my path to glory. After developing my technical skills, I solidified myself as a maven for writing great code and building great software. Negatively, on my career path, I came across many different people that end up not treating me for who I am. In my past, I've been often labeled as a "kid" or "inexperienced codemonkey" in the workplace. I believe that if someone wants to label me as that then they can--it's completely their opinion; however, someone shouldn't be completely ignoring my technical opinion because of the limited number of years I've been programming--That's ageism.

One thing that holds true about technology and design is that everything changes so fast. "Highly experienced developers" can legitimately be kids out of school nowadays because of how fast they learn new technologies and leapfrog over pitfalls. "Experience" is questionable now.

Conversely, in other industries, you can compare a carpenter with 40 years of experience to an apprentice carpenter--The difference is huge. If you compare a JavaScript developer with 20 years of experience to a Computer Science graduate--what can you honestly make out of this? 20 years ago, no one used JavaScript to create stunning animations, highly scalable network programs (NodeJS), or amazingly responsive interfaces. So why does technical experience matter? Results should matter. Does the person know how to "get things done"?

Even though I've run into these situations where I am a victim in some way of ageism, I reflect on these experiences and ultimately those experiences have made me a battle-hardened, better person. For a while now, I hold true to this: I am a person of integrity, maturity, and technical ability with a tad bit of facetiousness to break tense situations. You can take shots at me all you want but at the end of the day, I'll still treat you like a human being. Following this mantra has done wonders for me in terms of career, quality of life, and social life.

There are several people in my workplace that exemplify this heroic persona--you know who are. You guys are the real heroes.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, Cox Communications and Microsoft. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Wednesday, September 29, 2010

Why You (As A Developer) Should Question Technical Decisions

Many times throughout my career I've seen software developers take a lot of pain from their leaders. Throughout history, "leaders" have always been personified as an unstoppable wave in the ocean that everyone rides along with. One way--one direction--one man/woman's goal. A "leader" is the entity which has the final word. To some degree, I can't picture myself blindly following a leader without questioning his or her decisions--There has to be a reason for everything. Furthermore, you (as the developer on a team) should be asking "why" certain technical decisions are being made in specific situations. Positively, you may even end up saving a high degree of effort for your team just by having your leader realize how much of a bad mistake his or her decision was.

Decisions from a technical standpoint should always be strategic. One should always aiming for a goal to achieve and one should always have to look for key people, abilities, or events to transpire in order to make a strong, positive decision that best suits either the business or their team. Incidentally, being in the technical realm has its pains and pitfalls. In software development, a team captain has to take into account his or her experience, skill of his/her teammates, and the level of dedication they are willing to invest in building something heroic.

I live my life with this quote on my mind: "the only reason why you're unhappy is because you made yourself unhappy". There shouldn't be anyone to blame but yourself. This quote is generic enough to apply to anything: relationships, career, or school. Incidentally, from a career standpoint, I see many developers just tough it out without speaking up or challenging certain decisions from a superior officer. Ultimately: if you don't speak up and you have a feeling that a particular decision from your superior could inflict significant damage to your process, you'll end up shooting yourself in the foot.

It is always better to over-communicate than under-communicate. [Great] Technical leaders will listen to and acknowledge your opinion -- It's just a matter of voicing it out and backing up the facts. Be true to yourself. Be a developer. State your facts. "They" will listen. If they don't--then it is your time to move on.


Good luck and have fun,
Jaime Bueza


Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Wednesday, September 22, 2010

The State of 4N/WebSockets and NodeJS Hosting

4N + WebSockets

For anyone that wants to develop on a 4N (Not Windows, nginx, NodeJS, NoSQL) stack, I've come up with a list of gotchas that you will eventually run into when developing your applications.

nginx does not support web sockets

If you're building an application that will require WebSockts for full duplex bi-directional communication between the client and the server, you're sore out of luck as nginx doesn't support the WebSockets protocol (ws:// for normal, wss:// for secure) yet as of September 2010. Based on the discussions on the NodeJS Google Group, some have gone out to say that NodeJS shouldn't be out in the front. For clarification, nginx is a battle-tested Russian event driven web server that powers high traffic sites like Wordpress, Hulu, Github, and SourceForge. By using a single master process, it is able to easily handle 10s of thousands requests by delegating to worker processes. Each worker handles multiple requests in an event-driven or asynchronous manner using special functionality from the Linux kernel (epoll/select/poll).

Furthermore, NodeJS is also event driven and is powered by the non-blocking beating drum of an extremely fast event loop. As many of you know, NodeJS is a platform on top of Google's V8 engine that allows developers to write server side Javascript and build powerful, scalable networking applications.

npm versions aren't excalibur swords--Learn how to hack together a solution

As I understand it, a lot of developers trying out NodeJS are Rails enthusiasts that are open-eyed, wanting to explore the vast world of server-side Javascript. I could be completely wrong here about the demographic but one thing I do know is that "npm install ..." is not as reliable as "gem install ..."

For example, while trying to build an MMO pokemon card game on the iPad for NodeJS, I couldn't figure out why Sockets.IO wasn't working until I realized that the repository on github had fixes that npm's repository didn't. The quick fix? Hack it up! I merged the code from 'master' on github into /usr/local/lib/node/.npm/socket.io/0.5.3/package and it was smooth sailing from there. I notified the author of the library, he was gracious enough to inform me that it's already fixed in the upcoming code push to npm. Be warned--you will need to figure out some of these little things!

You may need to migrate to MongoDB, CouchDB, or MySQL (async driver)

If you're thinking about a rewrite of your application, you probably understand that your application will probably be the easiest part of the migration over to the NodeJS platform (it's just Javascript). The most difficult part in my opinion would be if you're migrating your data from an existing relational database. I would definitely not suggest that at all--What I do suggest is to migrate some of your frequently hit pieces of data (news, forum posts, etc) and have those migrated over...Or just not migrate your data if you're on MySQL/Postgres as there are an asynchronous drivers. If you're coming from Oracle, good luck.

NodeJS Hosting

- Gandi
- Joyent
- Heroku

Special Links of NodeJS Adoption

- THQ Selects Joyent To Provide Social Networking Infrastructure To Enable Rapid Prototyping And Deployment of Online Games
- Palm brings improved multi-tasking and NodeJS to webOS 2.0
- Plurk: Instant conversations using Comet
- Heroku adds NodeJS support

Tuesday, September 21, 2010

Why the web evolves so slowly in comparison to other industries

In technology, in one way or another, you will run into specific individuals that just don't care about their jobs. I've had to chance to see them infest my beloved discipline: software development. Time and time again, I see them dodge bullets from upper management by talking their way out of specific things that are too challenging or too lazy to take ownership of.

I work in web development: my role is to to develop cutting edge user interfaces, produce engaging online experiences, build intuitive software, and be a passionate technology leader. I've come to realize now after working in the agency business for so long that there are too many people that just don't care about the software they are actually building for their clients.

I've talked with several other developers from different companies and it appears to be the same. Consequently, I believe that the reason why we're forced to code like a drone is because a majority of other disciplines in the business don't understand what we really do as software developers. Furthermore, I believe that other disciplines actually think we build door knobs (components), that go into doors (applications), and the doors go to a house (technology platform). It's this imagery that completely dispels the drive and passion of building great software. In actuality, it is not that shocking. This happens time and time again, for example, in the gaming industry where it is very competitive--being on an old platform (SNES) could potentially cut off any chances of success for future games.

Back in 1996, Squaresoft ended their long, tumultuous relationship with Nintendo because Nintendo decided to go with cartridges, which didn't have sufficient memory to really give an engaging experience compared to FMVs (full motion videos)--so they ditched Nintendo for Sony PlayStation. Incidentally, this story was about how a game development company made the leap of faith because their old platform and archaic ways didn't provide them the features and advantage over their competitors they needed to deliver a solid product (Final Fantasy VII).

After reading this story--I had an epiphany. In game development, there is always this constant drive to create more engaging experiences. As technology evolves, so must your delivery whether it is a service or a line products. Many front-end developers tend to blame designers for being too heroic when time comes to deliver a working web application but I'm starting to see a different perspective. I don't necessarily think it is the designer's fault when they're told to design something cutting edge. They are just doing their job, and so are the developers. So, who do we blame for the lack of evolution on the web? Who do we blame when our competitors create better experiences at a lower cost and a faster delivery time? Who do we blame when the expectations of what you were building between the client and the delivery team are so divorced?

Why is it that the game development industry has had asynchronous non-blocking I/O 20 years before the web? How is it that games have been real-time for 20 years and just now there's a burst of web applications that are real time using web sockets?

I blame it on all the laziness and tunnel-vision technology leaders of our current day in web development. It's not the client, it is not the designers, it is not the lowly programmers that are anxious to build great things. It's the guys in charge of the technical decisions that are so lazy and closed-minded about learning new technologies that can help alleviate our development pains and speed up our delivery. Instead of adapting to how competitors are creating more engaging online experiences or evolving new techniques on top of more agile technology platforms, we leave it up to the guys in their garages to develop something brilliant and follow in their steps. The worst offender isn't the part where we aren't being a true leader--it is the thought of trying to copy a more technologically advanced competitor but on a slow, painful, and frustrating stack of technologies.

It is clear that everyone wants to evolve and build intuitive, useful web applications but how can you innovate when your technical leaders put a stranglehold on your creativity because of their negativity towards learning something new and building on top of more efficient platforms. Ultimately, web development is so full of arthritis. Douglas Crockford said that. In my opinion, techology should always be evolving to help the business reach its goals--Laziness should never be tolerated. If you want to just sit on your position, why don't you just become a doctor?

Douglas Crockford also said, "that's why software development is so slow, you basically have to wait for a generation to die off before you can get critical mass on the next good idea."

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Thursday, September 16, 2010

NodeJS Hack Session: MMO Pokemon with NodeJS/WebSockets



The primary focus of this proof of concept is to determine how easy it is to build real-time web applications for all iPad, iPhone, droids, Safari, Chrome users on top of NodeJS (non-blocking event driven server side Javascript platform). The proof of concept was built within 6-8 hours including the following:

  • Uses Express framework for server side Javascript development (inspired by Rails / Sinatra / Django)
    • Uses EJS for templating language (much like Django templates and symfony) -- allows partials and passing parameters into partials like symfony PHP
  • Real-time chat using WebSockets
  • Arena Queueing System for real-time competitive matchplay using WebSockets
  • HTML5 Audio
  • CSS3 transitions for all hand cards, tappable cards, transparent panels, rounded corners, drop shadows
  • Fallbacks for Firefox, IE
    • Firefox/IE will fall back to Flash socket
    • IE will fall back to XHR long poll if the user doesn't have Flash installed
  • NoSQL CouchDB for fetching users and soon cards, achievements, friend associations


Technologies Used



  • NodeJS (Server side Javascript platform)
  • WebSockets for real-time
  • CouchDB for users, *achievements, *friend associations, *cards


NodeJS Packages Used



  • Socket.IO for networking (npm install socket.io)
  • Express for MVC application development (npm install express)
  • CouchDB (npm install couchdb)


Lessons Learned and Thoughts


I didn't use nginx as a web server to front NodeJS because nginx can't proxy the WebSockets traffic just yet. Using Apache is pointless because that would defeat the purpose of using a non-blocking, non-threaded technology stack.


HTML5 Audio inconsistencies



Chrome can't play mp3s or wavs, only ogg audio files.
Safari can't play ogg files, but can play wav or mp3 files
Firefox can't play mp3 files, but can play ogg and wav files

Use an HTML 5 audio library for abstraction

NodeJS:
+ Quick turnaround for implementing both backend (using couchdb/mongodb/async mysql) and websockets) and frontend functionality (using express mvc framework)
+ Easy and fast install, compile node, and it'll work
+ Simple and convenient package manager like gem for Ruby/Rails called "npm" (Node Package Manager)

- Must remember to use asynchronous programming (callbacks, callbacks, callbacks, do not block) when doing 

  • database access
  • networking
  • disk i/o

For more information on how fast NodeJS is coming along: http://github.com/ry/node/wiki/modules

This is not a full game; as the intent was to accomplish the following goals

  1. Establish networking code for chat application within the game using WebSockets with fallbacks
  2. Establish networking code for Arena Queue System within game for competitive matchplay
  3. Use CSS3 to do all the rounded corners, animations, transparencies, and drop shadows
  4. Use HTML5 audio for hilarious interface sounds

Hopefully, this proof of concept will inspire other developers who want to shape the open Web into a more engaging experience (easy to build real-time web applications) on top of a broad subset of consumer technologies (iPad, iPhone, Droids, PC, Mac, etc).

If you're in the Vancouver area, shoot me an email at jbueza@gmail.com and I can give you a demo. Yes, it does look very sexy on the iPad with beautiful CSS3 animations.  :) Again, I'd like to reiterate this: my goal isn't to earn any money off this but to inspire others to join this initiative to create better web experiences for users across all technologies. Below are the source to the Pokemon card game on NodeJS with real-time chat, as well as, the real-time arena queue system for competitive match play.


github nodejs pokemon source (contact me if you can't set this up or if you have problems)

github nodejs arena queue system source

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Saturday, September 4, 2010

SimpleYUI, thoughts on NodeJS development

I've been a huge fan of YUI for a few years, even back when they were named YUI-Ext. Recently, they rolled out SimpleYUI. When asking other web developers why they don't like YUI, they say, "their package system is too complicated" or "you can't just start accessing the DOM by including the library easily". Incidentally, back in the day, it was far worse--YUI didn't even have a selector engine until they ported someone else's into YAHOO.util.Selector (remember this guy?). This design flaw in the library is probably what cost them in terms of people adopting YUI. As a developer, you want a consistent way of doing the most common things (dom access).

Back in the day, you would have to call YAHOO.util.Dom.get(element or string for ID of element). This was terrible because they introduced YAHOO.util.Selector.query(cssSelector) right after and soon developers were choosing between fetching DOM elements by selector or by ID. MooTools has the same problem but separates it in $() versus $$(). How about jQuery? $(cssSelector or element). Everything is passed as a css selector or a DOM element and it stays consistent through $(). I am certainly glad that they have aligned towards having a consistent API for fetching DOM elements. At my last job, some projects were using the old YAHOO.util.Dom.get('') and some projects had YAHOO.util.Selector.query(). With SimpleYUI, you're able to get the simplicity of how you're using jQuery but you also get the power of swapping back to using YUI's powerful packages.

NodeJS: why you should jumping in to help bring NodeJS into the production-ready realm


When people ask me about whether we should adopt NodeJS into a production-level deploy, I have to state the clear and obvious answer: no, it isn't proven yet and we would burn too much budget trying to seek the answers that haven't been answered yet.

Every single time I say that exact sentence a part of me gets disheartened. Why? Because saying "no" to it is the most responsible thing to say if you're a technology leader. What happens when your project goes overbudget because you didn't have the technical skill set to handle this new technology? You get blamed for trying to push it into production.

I understand that it is new and unproven; so the question is: what can I do to ensure that NodeJS can be fully integrated into production deployments (big builds or small builds). I have been asking myself this for quite some time now and I find it way too easy for someone to disapprove of NodeJS because of how unproven it is; so the best thing to do for the NodeJS community would be the following:

1) More Node Knockout tournaments (I've showed this off to my coworkers and they are highly impressed with the apps developed)
2) More technical writers and video producers (viral video for how to setup your website in 5 mins on Node)
3) More web hosting solutions than just Joyent/Heroku/Linode, let people start creating sites on top of a solid backend!
4) More enterprise solutions, such as, application server replacements like JBoss

The most exciting part about NodeJS isn't the fact that we can move towards fast real-time web applications, or the fact that you can scale out to more users with less hardware--it's the fact that it has never been done before. Furthermore, having Javascript run on the front-end and the back-end is the most exciting part about NodeJS development; if you find yourself without a challenge, try NodeJS out!

Incidentally, after watching Douglas Crockford's Loopage talk, he said, "That's why software development is so slow, you basically have to wait for a generation to die off before you can get critical mass on the next great idea" and "We're about to take maybe the most important step we've ever taken in terms of the technology fo the web and Javascript is leading the way. Who would ever imagine that? Javascript is the technology leader, it's not just the thing we tolerate." Such an inspiring speech by Douglas Crockford. That said, my passion for advancing software development has been lit once again. Good stuff will be coming out in the near future! Believe it!

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Tuesday, August 24, 2010

Develop to Developer: What is Passion?

Passion is what makes someone truly great. You can see just from glancing at a developer's application that an extensive amount of passion went into his or her work. Passion is not something you can forcefully create or define but you know it when you see it. Sometimes passion is misdirected into building things that are harmful to others. Sometimes it is the determination of one that makes a creation so great. Passion makes a person a hero, it makes a villain evil, and it definitely makes a front-end developer a true Ninja.

Passion makes software memorable. Passion awakens theoretical design and entangles us in its practicality. Passion is the engine that drives inspiration and ingenuity. I often wonder how technologically advanced the human race would be if it wasn't for some of the most passionate inventors of our time: Einstein (relativity), Edison (light), Arnold Schwarzenegger (bodybuilding)? People often ask me why I'm constantly trying to find newer, effective solutions for our present day web applications (performance, best practices, theoretical/conceptual research). With a smile, I can only say that I don't do it for the money--I do it because I love doing it. Everyone that has worked with me knows it--this is who I am.

I have come far in my training. *Ninja Vanish*

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

IE6 Downfall Is Coming, The Nail in the Coffin for IE6

The tides of darkness are slowly subsiding. I've come from a generation of front-end developers that have had to deal with every single IE6-related layout or JS bug in the book. Incidentally, I've been looking at the latest browser statistics on W3C and although your particular client may have more IE6 users, we can't deny the fact that the IE6 unicorn is about to die off in the coming years. It is happening. The day that I thought would ever come is edging closer and closer as I look at these web browser usage statistics.

My current client has mandated that all their sites drop IE6 support. This is a client that pulls in a huge amount of traffic hits a day and anyone who visits the site on IE6 will be thrown this message: http://code.google.com/p/ie6-upgrade-warning/.

This brings me to my question: are IE6 heroes needed anymore with declining usage? Do you remember the days when a client wouldn't launch the site because of IE6 performance issues? Do you remember when your client was raging about transparencies/drop shadows not being pixel perfect? Those were the good old days of broken bones, blood, and sweat. Newer developers that are coming into the front-end development scene don't deal with these kinds of issues at present day now that clients realize how terrible IE6 is and how 5% of traffic isn't worth doubling the budget on bug fixes. Have times changed, has launching a site become easy mode?

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Thursday, July 8, 2010

Blizzard Real ID to expose personal information of users on forums



Recently, we introduced our new Real ID feature - http://www.battle.net/realid/ , a new way to stay connected with your friends on the new Battle.net. Today, we wanted to give you a heads up about our plans for Real ID on our official forums, discuss the design philosophy behind the changes we’re making, and give you a first look at some of the new features we’re adding to the forums to help improve the quality of conversations and make the forums an even more enjoyable place for players to visit.

The first and most significant change is that in the near future, anyone posting or replying to a post on official Blizzard forums will be doing so using their Real ID -- that is, their real-life first and last name -- with the option to also display the name of their primary in-game character alongside it. These changes will go into effect on all StarCraft II forums with the launch of the new community site prior to the July 27 release of the game, with the World of Warcraft site and forums following suit near the launch of Cataclysm. The classic Battle.net forums, including those for Diablo II and Warcraft III, will be moving to a new legacy forum section with the release of the StarCraft II community site and at that time will also transition to using Real ID for posting.

The official forums have always been a great place to discuss the latest info on our games, offer ideas and suggestions, and share experiences with other players -- however, the forums have also earned a reputation as a place where flame wars, trolling, and other unpleasantness run wild. Removing the veil of anonymity typical to online dialogue will contribute to a more positive forum environment, promote constructive conversations, and connect the Blizzard community in ways they haven’t been connected before. With this change, you’ll see blue posters (i.e. Blizzard employees) posting by their real first and last names on our forums as well.

We also plan to add a number of other features designed to make reading the forums more enjoyable and to empower players with tools to improve the quality of forum discussions. Players will have the ability to rate up or rate down posts so that great topics and replies stand out from the not-so-great; low-rated posts will appear dimmer to show that the community feels that they don’t contribute effectively to the conversation, and Blizzard’s community team will be able to quickly and easily locate highly rated posts to participate in or to highlight discussions that players find worthwhile.

In addition, individual topics will be threaded by context, meaning replies to specific posts will be grouped together, making it easier for players to keep track of multiple conversations within a thread. We’re also adding a way for Blizzard posters to “broadcast” important messages forums-wide , to help communicate breaking news to the community in a clear and timely fashion. Beyond that, we’re improving our forum search function to make locating interesting topics easier and help lower the number of redundant threads, and we have more planned as well.

With the launch of the new Battle.net, it’s important to us to create a new and different kind of online gaming environment -- one that’s highly social, and which provides an ideal place for gamers to form long-lasting, meaningful relationships. All of our design decisions surrounding Real ID -- including these forum changes -- have been made with this goal in mind.

We’ve given a great deal of consideration to the design of Real ID as a company, as gamers, and as enthusiastic users of the various online-gaming, communication, and social-networking services that have become available in recent years. As these services have become more and more popular, gamers have become part of an increasingly connected and intimate global community – friendships are much more easily forged across long distances, and at conventions like PAX or our own BlizzCon, we’ve seen first-hand how gamers who may have never actually met in person have formed meaningful real-life relationships across borders and oceans. As the way gamers interact with one another continues to evolve, our goal is to ensure Battle.net is equipped to handle the ever-changing social-gaming experience for years to come.

For more info on Real ID, check out our Real ID page and FAQ located at http://www.battle.net/realid/ . We look forward to answering your questions about these upcoming forum changes in the thread below.

Update - Text updated to include more current and correct information regarding legacy forums and their use of Real ID. "The classic Battle.net forums, including those for Diablo II and Warcraft III, will be moving to a new legacy forum section with the release of the StarCraft II community site and at that time will also transition to using Real ID for posting."

I've recently stumbled upon Blizzard's Real ID system that would expose every one of Blizzard's WoW and Starcraft 2 customer first and last names on the official forums. This is a completely erroneous strategic decision from a business perspective and a gamer perspective. I will detail a few examples of how this system can be abused.

1) Real ID exposes womens' first and last names essentially giving stalkers a "goldmine"

Everyone knows that Battle.net is infested with single men that have never had sex before. Real ID will essentially open a "goldmine" for stalkers to harass these women that don't want to be known as a females in the gaming universe. Believe it or not, a lot of females play male characters because they don't want to get any attention from weirdos/creeps/stalkers/role-players.

Here is a chain of things that a potential stalker can do:
- Google the female's first and last name
- Find results that contain personal information on popular social networks, such as, Facebook, MySpace, Online Forums, Friendster, Twitter, or their own personal blog.
- Scan for anything related to their "first pet name, mother's maiden name, name of high school" are very common in "security questions" for password retrievals.

Notice that this can easily be achieved by any scan bot that will invoke Google search web services.

2) Real ID threatens the careers of those who care about their career

A really prime example is if you ever are questing and you get ganked by someone for a few hours--you end up getting mad and you post on the forums about the asshole who keeps ruining your ability to quest. This happens all the time. If you're a university student and you're looking for a job to get into the industry--you'll most likely be googled by your employer. They'll read your forum post and see how you've insulted someone for being ganked and won't even think about interviewing you. It happens.

3) Real ID threatens your children's safety

There are thousands of pedophiles scouring the WoW forums. If your child is playing World of Warcraft and they are actively participating in the forum, pedophiles will be able to get their personal information. Blizzard claims that parents will need to agree and allow their child to post their personal information with a checkbox. This is easily by-passed because most parents don't even understand the effects of having your personal information globally accessible.

Aftermath of Real ID

Since the general public are aware of the problems involved with Real ID exposing their personal information on the forums, people will most likely not participate anymore and will search out alternatives. This gives 3rd party community developers to possibly open up a forum to discuss WoW/Starcraft2 topics. This will be a huge surge in web traffic. If you're a community developer and you're dedicated to Blizzard games, you should definitely think about starting up and selling adspace.

Misunderstanding of Battle.net Goals: Battle.net is not Facebook, nor should be a "personal online experience"

As a software developer that has worked with several companies, I've seen this time and time again where the direction of strategic business decisions are completely divorced from what the business needs to be successful. Every company lives through this process but Blizzard's Real ID system being integrated into a hate-filled, sexist-filled, racist-filled, homophobe-filled, stalker-filled WoW forum is possibly the worst strategic decision they have ever made since Starcraft: Ghost. Subsequently, gamers have always been recognized by their "gamertag" cloaked by anonymity. An online gaming experience should never try to be a "personal gaming experience." Facebook is a personal online experience--Battle.net is not. Blizzard needs to disengage Real ID and re-align their business strategy. Hopefully, after this massive ****-up, they'll start building great products again.



Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Thursday, June 17, 2010

Blast Mojo Tutorial (Episode 4): How to use Publish/Subscribe with Mojo's Messaging Behavior



Publish/Subscribe is implemented in many applications and games as it is best
practice for keeping code loosely bound essentially increasing its level
of refactorability. In modern day web applications, your client keeps
requesting new features and you as the programmer need write code in a way
that will keep up with evolving business requirements.

I have a few blog entries written but I'm going to space them out more and release them
on a set schedule. Other than that, I've been having a lot of fun with my weekly sprints (self-disciplined coding) and Javascript tutorial videos.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Tuesday, June 15, 2010

Basic HTML 5 Audio Example on Github

Adding to it, I'll be integrating those sounds into a clone Javascript game. You can guess what that game is by the sounds I used! :) Here it is: http://github.com/jbueza/Basic-HTML5-Audio-Example

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Saturday, June 12, 2010

Dispelling Laziness, Getting Things Done, Helping non-programming programmers

I'll do it later. - Mr. Procastination

After reading Getting Things Done by David Allen about 3 months ago, I've become a productivity machine. I've evolved from working 9-5, sleeping early, being able to do programming sprints every month to doing sprints every week, starting my own YouTube channel, writing for several blogs on productivity/gaming, and engaging myself in a healthy lifestyle by going to the gym and sustaining an unforgiving 2000 caloric intake. What does it take? The answer is simple: discipline and passion.

I have to admit that when I first started this blog I wrote in a very robotic tone (much like the Architect from the Matrix). I've dispelled that and decided to take the direction of this blog to a more casual tone. I was listening to the Internet Business Mastery podcast and they talk about how the tone of your blog should always be as if you were talking to a person at a nearby coffee shop. This intrigues me so much and it purges the thoughts of "Is my writing good enough", "Do I need to sound more intelligent?". That said, I believe that the first steps to achieving creativity and productivity is to purge your ego, your dwelling thoughts of failure, and your tendencies to get discouraged.

Never give up.

I've recently launched my own personal project called Nice Macros Bro, which is a simple repository of macros for World of Warcraft players. Although I have quit the World of Warcraft almost a month ago, I still decided to go along with making the site as my goals were to exercise my SEO skills and dive deeper into Google Analytics' metrics.

Adding to that, I've launched my personal portfolio that encompasses a plethora of projects I've done including Mojorion and XWNED Dashboard. So, it's been a very productive past few months--all thanks to reading Getting Things Done by David Allen. Additionally, a major kudos to Loyal Chow for recommending it to me.

Helping Non-Programming Programmers

You probably noticed that my past few articles have been giving advice and tips to aspiring front-end developers that don't really have the technical Javascript skills but are able to do HTML/CSS easily. Here's a few of the articles I posted so far:
Coding Horror's article on Non-Programming Programmers evokes his hatred towards non-programming programmers.
At least bad programmers can be educated; non-programming programmers are not only hopeless but also cheapen the careers of everyone around them. They must be eradicated, starting with simple technical programming tests that should be a part of every programmer interview. - Jeff Atwood
Technology would have never evolved so much without the industry being so bloated with a wide spectrum of experts and amateurs. Adding to that, it is very easy to create web sites nowadays--making it really easy to solidify a non-programming programmer's portfolio. I've worked with all people of the spectrum and based on my experience, NPP's don't have that much of an effect on timelines. At the end of the day, they are still able to ship the HTML/CSS/Javascript. Sure it'll be spaghetti--but that's up to his/her architect to code review. What I also do find is that sometimes NPP's may not be strong in terms of technical skills but they will have a strong set of soft skills (negotiation, which is a valuable skill to have when making technical recommendations to the client). That said, front-end development is good where it is by having a wide variety of people with diverse backgrounds. Some front-end developers come from a Bachelors of Arts and not Computer Science or Computer Engineering. I believe that having a diverse group of developers brings in more potential creativity in solving problems; however, if the developer isn't passionate about what he's doing--it's a totally different ballgame.

What I do find very disheartening in front-end development is sometimes you will have team mates that just don't care about what they are doing. Since the level of entry for front-end development is very low (easy to get in) and the rewards are very high (pays well)--you'll often run into these types of people that only care about the money.

In the end, I see having NPPs (non-programming programmers) on the team as an advantage. Subsequently, it gives your team diversity and opens up the potential of attacking problems from different angles. Most of them are able to still finish their deliverables; However, NPPs that don't show the slightest bit of passion and dedication in front-end development can cause a disturbance in your team synergy.

I believe that the interviewing techniques of todays programmers need to change. Human Resources should not be conducting a technical interview--a senior developer or architect should be. Also, technical interviews should encompass both highly technical questions and story-based questions to really pin-point whether the candidate has a certain level of passion and dedication for development. Even if they don't manage to fully answer the technical questions, they can still show how 'trainable' they are based on if they can convey to the interviewer that they're passionate, dedicated to learning more.

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.

Thursday, June 10, 2010

Upcoming Javascript Sprint Projects

I haven't contributed to Github for a while now since I've been so submersed in work lately. I'm planning an upcoming Javascript sprint this weekend to hopefully tune my level of Javascript architecture, work with an exciting new feature (audio, video controller in HTML 5), and refuel my inspiration for front-end technologies.

Lately, I've been thinking about a pluggable Audio Controller for HTML 5 web games that can take into account character movement, character responses, and music tracks. The more I think of it, the more I get inspired to get started but I have this huge list of things to pencil out:

  • How does the native audio support in modern HTML5-capable browsers affect the performance of the application?
  • Can I lazy load audio tracks by dynamically injecting the audio track into the DOM?
  • Can I programmatically set auto buffering?
  • Can I observe the audio object in question and hook into its events with Blast Mojo?
  • Can audio objects play at the same time? or do they get queued?
  • ...more to come
Small thoughts on a big subjects. I'll give a shot this weekend and see how it goes.

Cheers,
Jaime

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.