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.

"HTML5" Is A Marketing Gimmick -- What can you do with HTML 5?

As many of you know, Apple released a web site talking about the advantages of implementing web applications with HTML5's features. While I completely understand their initiative to indoctrinate people into a full-featured family of technologies, I can easily see through the cloak of Apple's marketing team.

Do you remember back in the day when people used the term "ajax" (and they still do) to send off the message to the public that "ajax" is the product and not a stack of technologies that are implemented within the product? HTML5 is following in the same foot steps. I highly urge the non-technical, aspiring web entrepreneurs to read up on what exactly HTML5 is or you will be misled by undisciplined web developers claiming HTML5 is the driver in the product. Wrong. HTML 5 is a specification to a plethora of features that modern browsers will hopefully choose to support.

"This is cutting edge shit, dawg." - Noob software developer

Prior to this, I've already said my opinion that "HTML 5" is being marketed to the crowd but sending out the wrong message of what it really is. Did you read the spec? Great. Now that we're on the same playing field, let's talk about what you can do with HTML 5.

"Okay, thats cool, but now what?" - Aspiring non-technical web entrepreneur with great ideas for products

LOOK ME INTO THE EYES AND GIVE ME YOUR SOUL. Just joking. So, now that we understand that the term "HTML 5" is a subset of technologies that we can leverage in building rich user interfaces, let's outline the possible platforms that support it.
  • Windows/Mac OS X Safari
  • iPhone Safari
  • iPod Touch Safari
  • iPad Safari
  • Windows/Mac OS X Google Chrome
  • Firefox 4
"So, what can I do on those supported platforms?"
  • Build applications with your own typography. You are no longer constrained to web-friendly fonts or Flash font replacement!
  • Build applications using native audio support
  • Build applications using native video support
  • Build applications using 2D/3D transitions and transformations
As you can see, some of the constraints that we deal with today in web application development, such as, achieving interactive video, sound, custom typography are dependent on Flash technology. I'm not hating on Flash--but it has its place, not in web applications or mobile web applications. Apple's iPad and iPhone market share is rising and people are on a more advanced platform that will never support Flash. As an entrepreneur, you need to build a product on top of market that is fresh, growing, and provides an familiar stack of technologies to easily streamline products.

If you disagree with me, yell at me in the comments. Discuss!


Cheers,
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.

Friday, June 4, 2010

Prioritizing Software Defects


Often times we're overwhelmed by a number of critical defects that need to be fixed "ASAP". If you're using an issue tracker, you have the ability to prioritize issues but what happens if all your issues are the highest priority (blockers)?

A trick that I utilize in my work-flow is to figure out what dependencies each issue has. I ask myself the following questions for each defect assigned to me.

1) Is another teammate dependent on my fixes in order for him to get his job done?
2) Is this issue really stopping the launch? Is there a quick solution that the client is willing to go with in order to successfully launch?
3) Do I need third party support on this issue?
4) Who do I need to talk to get the necessary information to fix this issue?

From the questions above, you can really start to figure out which software defects you should be fixing first. Here's my opinion on what the queue should be:

1. Teammates come first

The issues you should resolve first are the ones that other teammates are dependent on in order for them to get their job done. A perfect example is if you're providing core functionality in a library and other developers are building components on top of your code. There will be a point where your teammates won't be able to progress as they can only do so much with limited testing.

2. Find out what information you need to fix the issue

If you find yourself scratching your head over what the client wants out of an issue; you should fetch that information ASAP. You should never have to assume functionality--always figure out what the clients' intentions are. This approach leads to less bugs sprouting from what you thought was a fix but really wasn't.

3. Third-party support has a time-limit

If you've ever had to call a support line to get help on third-party integration (cough, Liferay, cough, Omniture), you'll know that their work hours are the usual 9-5. Incidentally, this means that your time-frame to resolve integration issues is very tight. Generally, whenever you have to get support from a third-party your whole team (even the client you're working for) should assume that it can be painfully slow or inadequate. I'm not saying Omniture is bad--From my own experience, I think they have the best support: very helpful, very responsive.

4. Is it really a defect or is it a change request?

This is a big question most of the time and requires you to have some back-bone. In most cases of software development, clients will always try to ask you for extra functionality or extra features without having to pay for them. A really easy way to spot this is if they categorize the change request as a "software defect". A prime example would auto-completion on form fields when the requirements don't specify that fields have auto-completion--a client response would be, "well all fields should have auto-completion because X, Y, Z, A, B, C sites have it." It's very easy to say that but in reality it would require a significant amount of effort to implement that site-wide. Firstly, each field would need to have a data source (auto-completion suggestions), secondly testing all the fields in all browsers. Sometimes, it's just not worth it and you have to do your best to convince the client that it would eat away at the budget (development time and QA time) for such an "enhancement".

Furthermore...


What are your thoughts on how to prioritize software defects? Project Unnamed horror stories with how defects are prioritized? Post in the comments below.


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.

IE6 problems with Flash and Gzipped XML

Flash Logo

Hey all,

This is a repost of my entry back in 2007 since I'm slowly moving all my posts over to here. This does seem a bit cheesy but I might as well throw it in here since blogspot is my blogging home now.

Problem Analysis

While doing some front-end performance enhancements on a project that utilized extensive javascript and flash, I found that IE6 doesn't like it when you compress text/xml with mod_deflate/mod_gzip. From a user perspective, the Flash component would show, but any XML data being transferred to the Flash component will be rejected--you get a blank canvas/UI without any data/Preloader will show. Incidentally, Internet Explorer 7, Firefox 2+, Safari all handle gzipped text/xml without a problem.

Final Solution


Only apply gzip to the following content types: text/plain, text/html, text/javascript, and text/css--Do not apply it to text/xml if your Flash components use XML data sets from the back-end.

This solution gzips all your assets (Javascript and CSS), without breaking Flash components in your web application.

Further Reading

mod_deflate
tutorial - http://www.howtoforge.com/apache2_mod_deflate


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.

Tuesday, June 1, 2010

Job Interview Tips for a Front-End Developer: Show How Passionate You Are

As my nervousness rises, my palms begin to sweat. I've been summoned for a job interview. There's a plethora of questions and answers ping-ponging through my mind as the time ticks closer to the interview. With my confidence banked on my experience, skills, and knowledge, I'm guaranteed this job--so why am I nervous?

The receptionist enters, "Mr. Anderson?" I look up, "Yes, that's me." She smiles, "Mr. Smith will see you now."

I thought I would open this blog with a different approach--it's one of those memorable experiences that you'll always keep getting every time you go for a job interview. The feeling of nervousness, the thoughts buzzing through your head like a bees nest, and the prediction of your outcome.

The Sad State of Front-End Engineering

After conducting job interviews on a number of front-end developers, I've come to realize that my discipline (front-end engineering) is saturated with non-programming programmers. Programming is an art, much like a Martial Arts--there are people out there that can get by and be successful using the skills/techniques without actually understanding the discipline. Surely, I believe that this has happened because of the fact that 'anyone' can really jump into building web sites. The Internet encompasses a plethora of tutorials that show how any person can copy paste (control C, control V) and voila, the page is done. The problem here comes from the lack of fundamental knowledge.

  • How do I contain multiple floats inside a container? 
  • How do I give an element layout in IE? 
  • Why is eval() evil? 

These questions really escape the undisciplined web developer on a day-to-day basis. Subsequently, I feel like the title 'front-end programmer', 'front-end developer', 'front-end engineer' is given out too easily. I am a firm believer that a true developer shows passion in what they do, as well as, understands the fundamentals of how/why things happen.

How passionate are you about Front-End Engineering?

When the interviewer asks you this question:
  • Based on your past project experience, in your opinion, what was the most challenging feature you had to develop? 
This is a blessing in disguise. This provides you with the ability to pick out a particular feature you've developed and talk about the techniques you've implemented, the push-back you've done with the designers, as well as, outline the lessons you've learned. Tone is everything while telling your interviewer about your experience. Show him that you are a passionate developer: you take pride in your work, you are dedicated to your discipline, and you are constantly trying to learn more. You can single handedly get the job based on your response if you evoke an emotional response from the interviewer. To me, when I see a developer really showing me how passionate he is about front-end development, it strikes me emotionally. As a more experienced developer, I love working with other developers that are just as passionate as I am about front-end engineering.

How technical are you?

Even if you can't fully answer the technical questions, do not be discouraged. If you can't answer them, at least give it a shot. One thing that I've noticed is that candidates full-stop themselves if they can't answer the typical, "how would you write a fibonacci method in Javascript? How does fibonacci relate to Javascript implementation?", "What are the 4 types of 
method invocation in Javascript?", and "how many methods do you know for triggering hasLayout in Internet Explorer".  Even though these questions can be quite technical, they test your thought process. Are you a programmer or not?

  • Prior to developing an application, what are your first steps when analyzing a mock-up given to you by a designer?
Initially, this should raise flags in your mind as soon as possible. This is a test of your critical thinking abilities. We live in a Web age of really complex user interfaces, so think about the commonalities.
  • Can we re-use the drop shadows across all modules?
  • Can we re-use the rounded corners?
  • Are the fonts aliased so that they are more realistic in terms of Internet Explorer 6?
  • Are the fonts web friendly?
  • Are the states in the mock all complete?
  • Are you able to tell the designer to reduce a certain component's transparency to make IE6 development not-so stressful?
  • Can we sprite all the buttons, icons, etc? (Save http requests)
  • Is the design screen resolution friendly? (1024x768)
  • Is there a Flash piece where your application has to have elements ovelapping?
  • Will I have to use CSS Grids (OO CSS, Blueprint CSS, etc) to maximize re-use?
  • Will I have to develop re-useable, re-skinnable components? (Accordions, Filmstrips, Slideshows)
Of course, this is just a small list of things to cover during a job interview. 

When applying for front-end jobs, applicants should start indoctrinating some of the thought process I've listed above. Some job interviews might be purely technical--asking only the evil questions about Internet Explorer or perhaps some of the deeper intrinsic features of Javascript. Ultimately, you can't go wrong with the advice above. If you disagree with me or have other suggestions to add, put them in the comments below.

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.