I want to know what the next best step is to advance my career. I was either thinking of picking up ruby or start mobile application development.
Any advice towards any direction will be phenomenal.
Thank You
I'm going to rattle off a few questions that come up as part of the daily job duties of a Google Frontend SWE, and may frequently show up as phone screen or "warmup" interview questions (the actual coding problems are under NDA and tend to get banned when they appear in public, but these are basic enough that I don't think my coworkers will mind):
1.) Why might you choose an iFrame over XHR for communicating with the server?
2.) What are some ways that you can get JavaScript onto a third-party website that can then communicate with your server and display some data on their website?
3.) Can you write a DOM traversal without using JQuery or other third-party libraries? Why would you want to?
4.) Which DOM API calls are slow and what alternatives do you have for them?
5.) Say that you have too many CSS rules for IE and need to come up with a quick fix that doesn't involve refactoring your CSS into something more sane or reducing the number of CSS rules. How might you do this?
6.) Which tags are self-closing in HTML5? Which tags may be omitted entirely? You can look them up, but which site would you go to?
7.) How do you make an AJAX app back-button aware in different browsers, and how will HTML5 help this?
8.) How might you track that a user has clicked on a link, and again, how might HTML5 help this?
9.) Do you know about Canvas, localStorage/sessionStorage, the <video> tag, WebGL, and various other HTML5 goodies?
10.) How do you write custom attributes on HTML tags in HTML5?
All of these come directly from actual problems we've faced at Google, BTW. If you know 'em, great - I'd pick up one of Python or Ruby and learn how the server works (and we're hiring, BTW). If you don't, I'd go deeper before going broader.
All of the questions, BTW, boil down to one meta-question: do you think about the whole user experience (including latency, stability, integration with third-party sites, and other UX conveniences), or only about putting pixels on the page?
(Edit: Also, Patrick's advice is great. My advice is mostly training you how to make yourself more valuable as an employee. His is training you how to make yourself more valuable as an entrepreneur. The two skillsets are not mutually exclusive - hell, I became an employee because I needed to learn some skills so I could become a better entrepreneur - but they optimize for different paths.)
1) Iframe over XHR. Not quite sure. I have used iframes to load a print version of a page and print it without redirecting the user. Other than that, perhaps I would also use frames to get a fully rendered response from the server and just append the html to the existing dom (so as to keep XHR for data only responses). Or load a bunch of templates. Or just use iframes for what they really are, embedding other webpages into the existing one.
2) One method that looks bullet-proof is what olark has done: https://github.com/olark/lightningjs Takes care of xhtml vs html, bad code, bad browsers and lots of other stuff (performance).
3) Yes I can. Years ago I used while() and was excited to find out that it's actually a good solution. I wouldn't load a library when it would make the experience less better.
4) I would guess dom manipulation, append, insert and the like. I always remove the parent element and then put it back in when I'm done with it. innerHTML is also fast and appropriate sometimes.
5) I can't understand the problem/question. Can you elaborate?
6) Off the top of my head: input, br, hr, meta, link, img. Omitted entirely? Not sure but I would say body and html. I would search and choose one of the top results. If its stackoverflow, w3c specs, htmldog I wouldn't worry.
7) Use location.hash. I wouldn't know how to implement it my self (IE needs an iframe from what I understand, Safari has/ad its own issues) but there are a bunch of libraries out there to do it for me. HTML5 has pushState, yay!
8) Good question. Considering only HTML and CSS I would use CSS colours (but not background-image, that was fixed). As for HTML5 I can't think of something.
9) I know and read about those but never used them, except for persistent storage.
10) With the data- attribute.. Or you can write your own doctype. Ha!
4.) That's one of the big ones. Also, adding new CSS rules to the page is really slow because it forces a reflow. Basically anything that forces a reflow and makes the browser repaint the whole page will be slow.
5.) IE6-8 has a limit of 4095 CSS selectors in a single stylesheet (it's good to know that limit, because additional CSS rules are simply dropped silently). It's not terribly hard for a relatively complex webapp to hit that limit. The solution is simply to break the CSS up into multiple <style> tags (or stylesheets, if you're using external CSS). The hard part in this question is understanding what the problem is, not how to fix it - many frontend devs aren't familiar with arbitrary browser limitations.
(This question came out of an actual problem that Google+ faced about a week after launch.)
6) Also li, dl, dt, tr, td, th, etc. The specific ones don't matter so much as understanding that you go to the spec to figure it out, not to w3schools. Also, the official spec is at WhatWG.com, not at the W3C site.
8) Oh, I was talking about tracking it yourself on the server (for logging/algorithmic purposes), not about displaying it to the user. Anyway, for user display there's the :visited pseudo-class. For logging, there're a bunch of alternatives like going through a redirector or adding some JS that makes an XHR or image request, but the HTML5 solution is <a ping="...">, which unfortunately is still buggy in most browsers.
Don't care about money and want some more opportunities for fun stuff? Pick up enough Ruby/Rails (or Python/Django) to implement your own backends. This lets you deliver whole projects (for yourself or others) without needing assistance.
