I was looking through the slides from jcon today. I really wish I could have gone; it looked like it was awesome.
I noticed that Yehuda Katz was a speaker. He's also a member of the Ruby on Rails core team, and I have been hearing rumors that Ruby on Rails doesn't scale well.
That rumor is a thorn in my side because I am interested in learning Ruby on Rails, but I want to be able to use it on a potentially enterprise level...
I sent Yehuda Katz an email, complimenting his slides and asking about the scalability of Rails and telling him that I had heard it didn't.
He replied with the following, and I thought it would be a good idea to share, just so anyone else who is interested could add their input.
"People who say this don't really understand what scaling is. Scaling is not about the performance of the VM, it's about fundamental architecture. Rails uses the REST architecture, the same architecture used by the Internet itself. It provides strong mechanisms for both server-side and client-side caching. It's the only framework I know of to implement all of the server-side recommendations in YSlow. Rails is, in fact, a high-performance framework. If someone says Rails can't scale, ask them what exactly they mean."
So, let me ask you...
If you say Ruby on Rails can't scale, what DO you mean?
About Me
- Matthew Maxwell
- Experienced Web Developer using C#, ASP Classic (VBScript) and ASP.NET, MySQL, T-SQL, and other SQL variants, JavaScript (W3Schools Certified and very well versed in jQuery and learning Dojo), and XML. Heavy interest in JavaScript, framework creation on various language platforms, and keeping up with the best industry-accepted practices.
Tuesday, September 15, 2009
Sometimes the DOM IS better.
I've been working with jQuery a lot lately, and, for the most part, it has never given me any issues.
I have noticed lately, though, that when it comes to using any append/remove/find function in the jQuery library, if it is on items that have a lot of data, jQuery has serious performance issues.
The example I ran into today was, I have a drop down that has a lot of users in it. It's somewhere around 4,000 options.
I normally find the selected option's text using
This takes about 2 seconds or so for jQuery to do. I believe it's because jQuery's find method isn't optimized for large traversal like that.
I wound up making a quick jQuery extension lgtext(), which is simply:
This worked A LOT faster than jQuery. In fact, it was pretty much an instant return.
The jQuery appendTo method only has a few milliseconds in lag time, so I left it in. It's enough to notice a slight pause, but not enough for it to really affect production.
jQuery's .remove() is also very slow on this select field, taking about 2 seconds to complete as well.
To combat this, I created my own extension, lgremove():
This works perfectly, and is also an instant completion.
These are the only issues I've ever had with jQuery, so that should say something about the library.
It is pretty solid.
Just to clarify, the 2 seconds of lag time was in Chrome. I was too scared to see how many times longer it would be in IE...
For you jQuery veterans out there, is there a better way for me to approach this using the built in jQuery methods?
I have noticed lately, though, that when it comes to using any append/remove/find function in the jQuery library, if it is on items that have a lot of data, jQuery has serious performance issues.
The example I ran into today was, I have a drop down that has a lot of users in it. It's somewhere around 4,000 options.
I normally find the selected option's text using
This takes about 2 seconds or so for jQuery to do. I believe it's because jQuery's find method isn't optimized for large traversal like that.
I wound up making a quick jQuery extension lgtext(), which is simply:
This worked A LOT faster than jQuery. In fact, it was pretty much an instant return.
The jQuery appendTo method only has a few milliseconds in lag time, so I left it in. It's enough to notice a slight pause, but not enough for it to really affect production.
jQuery's .remove() is also very slow on this select field, taking about 2 seconds to complete as well.
To combat this, I created my own extension, lgremove():
This works perfectly, and is also an instant completion.
These are the only issues I've ever had with jQuery, so that should say something about the library.
It is pretty solid.
Just to clarify, the 2 seconds of lag time was in Chrome. I was too scared to see how many times longer it would be in IE...
For you jQuery veterans out there, is there a better way for me to approach this using the built in jQuery methods?
Monday, September 14, 2009
Let's keep it DRY, folks.
If there's one thing I've come to love more than anything else in programming, it's the concept of DRY (Don't Repeat Yourself).
Seems like common sense, doesn't it? I mean...really -- DUH!
As common sense as it may seem, there are a lot of people out there who do repeat themselves. In fact, I used to be one of them! I have been spending a little extra time lately sitting down and seeing what I can functionalize because what may initially seem like added work from the tried and true copy-paste method, can actually save you a ton of time not only in later stages of development, but also in instances where you need to debug and make additions to your applications.
Let's look at the run down on DRY coding in JavaScript and why it's useful.
As any programmer with even a little bit of experience can tell you, requirements for projects are normally constantly changing. It's because of this constant change that the DRY style of programming really shines. As the criteria change, if you weren't using DRY methods of coding, you would have to make changes in multiple locations. Keeping it DRY allows you to make a single change and be done with the modification.
Let's face it-- everybody hates debugging.
Imagine you're debugging an application that's a few thousand lines in code. You spend an hour or so on it and finally find the issue that's been causing it all. You tried to call the getElementById method of documnet, which is undefined.
Too bad you copied/pasted this functionality into about ten different places...
Now imagine that you utilized a functionalized method in those ten places. You find the error sooner because you're digging through less lines of code, and when you find it, you only correct it in one place and then you're done! The same goes for making changes to that functionality. You make the addition in one place and you're done!
Seems like common sense, doesn't it? I mean...really -- DUH!
As common sense as it may seem, there are a lot of people out there who do repeat themselves. In fact, I used to be one of them! I have been spending a little extra time lately sitting down and seeing what I can functionalize because what may initially seem like added work from the tried and true copy-paste method, can actually save you a ton of time not only in later stages of development, but also in instances where you need to debug and make additions to your applications.
Let's look at the run down on DRY coding in JavaScript and why it's useful.
As any programmer with even a little bit of experience can tell you, requirements for projects are normally constantly changing. It's because of this constant change that the DRY style of programming really shines. As the criteria change, if you weren't using DRY methods of coding, you would have to make changes in multiple locations. Keeping it DRY allows you to make a single change and be done with the modification.
Let's face it-- everybody hates debugging.
Imagine you're debugging an application that's a few thousand lines in code. You spend an hour or so on it and finally find the issue that's been causing it all. You tried to call the getElementById method of documnet, which is undefined.
Too bad you copied/pasted this functionality into about ten different places...
Now imagine that you utilized a functionalized method in those ten places. You find the error sooner because you're digging through less lines of code, and when you find it, you only correct it in one place and then you're done! The same goes for making changes to that functionality. You make the addition in one place and you're done!
A really good way to implement DRY programming is by creating or using pre-built JavaScript libraries.
Using a JavaScript library, you utilize reusable, functionalized code that can really decrease dev time, increase performance and make your code look a lot cleaner.
There are some really good libraries out there.
Some ones you may want to look into are (in no particular order):
I use jQuery. It was the first library I stumbled upon and it's suited my needs perfectly. Each library has its strengths and its weaknesses, so be sure to check them all out before deciding which one to use.
John Resig also wrote a very good blog about Building A JavaScript Library
The concept of DRY can easily be adapted to any programming language. The reason I chose to talk about it in JavaScript is because that is the language I am most familiar with, but the logic is sound in any language that can utilize functionalized code.
Do you have any good examples of DRY programming? All languages welcome!
The concept of DRY can easily be adapted to any programming language. The reason I chose to talk about it in JavaScript is because that is the language I am most familiar with, but the logic is sound in any language that can utilize functionalized code.
Do you have any good examples of DRY programming? All languages welcome!
Books I've read and approve Part 1
Over the past few months, I have been completely enveloped in a new (to me) set of JavaScript conventions/ideas, and it's changed the way I program completely.
I went from messy global variables left and right, unorganized functions, repeating myself a TON, to neater, cleaner, easier-to-read code that relies on JavaScript libraries/namespace-like functionality.
Two books that I have read helped me make this leap, and make it a TON easier, too.
In no particular order:
Pro JavaScrip Techniques by John Resig
This book was awesome. It had a ton of information, and it taught me a lot. I like the way Resig writes. He doesn't really do a bunch of convoluted examples; he's pretty straight forward. X can be accomplished Y way, but it's more efficient to do it like Z and here's why. There were some typos here and there, but all-in-all, the book is sound. It also comes complete with a boatload of awesome Appendixes, one completely dedicated to Events! Hell yes! I would definitely recommend this to anyone, in fact, if you want to borrow it from me, hit me up!
JavaScript: The Good Parts by Douglas Crockford
For those of you who don't know Crockford, you need to watch some of his videos; the man is hilarious. I find him kind of cynical, but I love it. He's not afraid to tell it like it is, whether or not you like it. This book was pretty small, but don't let it's size fool you -- it had a lot of really awesome information. He may seem rough around the edges, but deep down, Crockford is a man after my own heart. He recognizes the elegance and power of JavaScript and really brings its beauty to light.
I am all about reading awesome books about programming, so if you have any, feel free to post them here. I am always looking for a good read.
I think it's safe to say, JavaScript has pretty much taken over.
I recently bought Agile Web Development with Rails by Sam Ruby, Dave Thomas, David Heinemeier Hansson, and I've just started it.
I am extremely interested in how programmer-friendly RoR is.
I would love to hear some opinions from RoR veterans.
I know there are rumors about how it doesn't scale well, so I'd love to hear solid conversation on that aspect as well!
Well, until next time -- have a good one!
I went from messy global variables left and right, unorganized functions, repeating myself a TON, to neater, cleaner, easier-to-read code that relies on JavaScript libraries/namespace-like functionality.
Two books that I have read helped me make this leap, and make it a TON easier, too.
In no particular order:
Pro JavaScrip Techniques by John Resig
This book was awesome. It had a ton of information, and it taught me a lot. I like the way Resig writes. He doesn't really do a bunch of convoluted examples; he's pretty straight forward. X can be accomplished Y way, but it's more efficient to do it like Z and here's why. There were some typos here and there, but all-in-all, the book is sound. It also comes complete with a boatload of awesome Appendixes, one completely dedicated to Events! Hell yes! I would definitely recommend this to anyone, in fact, if you want to borrow it from me, hit me up!
JavaScript: The Good Parts by Douglas Crockford
For those of you who don't know Crockford, you need to watch some of his videos; the man is hilarious. I find him kind of cynical, but I love it. He's not afraid to tell it like it is, whether or not you like it. This book was pretty small, but don't let it's size fool you -- it had a lot of really awesome information. He may seem rough around the edges, but deep down, Crockford is a man after my own heart. He recognizes the elegance and power of JavaScript and really brings its beauty to light.
I am all about reading awesome books about programming, so if you have any, feel free to post them here. I am always looking for a good read.
I think it's safe to say, JavaScript has pretty much taken over.
I recently bought Agile Web Development with Rails by Sam Ruby, Dave Thomas, David Heinemeier Hansson, and I've just started it.
I am extremely interested in how programmer-friendly RoR is.
I would love to hear some opinions from RoR veterans.
I know there are rumors about how it doesn't scale well, so I'd love to hear solid conversation on that aspect as well!
Well, until next time -- have a good one!
References in JavaScript
So, I've been getting more refined in my usage of JavaScript, and I've stumbled across a functionality that I knew existed, but didn't know that it existed to the extent that it does, and it's really made me kind of happy.
Since JavaScript is standard at my job, I get to use its glory in every application I create! Woot!
As many people know, one of JavaScripts flaws is that it's a language that is based on global variables.
Douglas Crockford says this is evil, and I have to agree. It gives a lot of room for libraries and plug-ins to collide with each other and make an awful mess.
In the current portion of the project that I'm working on, I am setting up an administration page to allow people with a certain level of access the ability to completely edit call records in anyway they see fit.
I use jQuery's datepicker (with a modified theme created by theme roller) for the calendar (you should check it out here), allow the user to submit a date range and an employee to pull back call records for and then list the call records out in a nice list for them to select which one they want/need to edit.
They then select the individual call, which is listed by Submit Date and Customer ID. That brings them to the view/edit page.
I pull back all the call's information via AJAX to an ASP validation page. My ASP page formats the data in a JSON format, and using Douglas Crockford's json_parse function, I am able to parse the XML into an easy-to-use JavaScript complient JSON object.
Neat.
My initial thought was to create a global variable to house the call record that was currently being edited...icky...and then it hit me. Maybe I can pass the internal object to all of my functions that edit/update, and maybe--just maybe, it will update the object, keeping all the references current, which would allow me to skate by with no additional global variables!
So, I tested it...and it worked!
I ran editStuff and then updateRecord and the new value stuck!
Just another reason why I love JavaScript.
Since JavaScript is standard at my job, I get to use its glory in every application I create! Woot!
As many people know, one of JavaScripts flaws is that it's a language that is based on global variables.
Douglas Crockford says this is evil, and I have to agree. It gives a lot of room for libraries and plug-ins to collide with each other and make an awful mess.
In the current portion of the project that I'm working on, I am setting up an administration page to allow people with a certain level of access the ability to completely edit call records in anyway they see fit.
I use jQuery's datepicker (with a modified theme created by theme roller) for the calendar (you should check it out here), allow the user to submit a date range and an employee to pull back call records for and then list the call records out in a nice list for them to select which one they want/need to edit.
They then select the individual call, which is listed by Submit Date and Customer ID. That brings them to the view/edit page.
I pull back all the call's information via AJAX to an ASP validation page. My ASP page formats the data in a JSON format, and using Douglas Crockford's json_parse function, I am able to parse the XML into an easy-to-use JavaScript complient JSON object.
Neat.
My initial thought was to create a global variable to house the call record that was currently being edited...icky...and then it hit me. Maybe I can pass the internal object to all of my functions that edit/update, and maybe--just maybe, it will update the object, keeping all the references current, which would allow me to skate by with no additional global variables!
So, I tested it...and it worked!
I ran editStuff and then updateRecord and the new value stuck!
Just another reason why I love JavaScript.
Some reasons why I love programming (long intro)
Let me preface this with the story of how I got started into programming.
So, I started dabbling in programming probably about 6 years ago. My friend, Zach, told me about it, and it peaked my interest. I thought it sounded fun. I was a little intimidated by the strict-typed object-oriented C#, so I decided I wanted to start with a scripting language that had "flexibility", so I started programming in Perl, haha.
I loved the idea that it was super flexible, and that I could say "Do it", and Perl would usually always comply.
I didn't use Perl too much. I made a few hello world applications, and my biggest project was a D&D character roller, haha. I eventually dropped Perl and took a break from programming. The language just wasn't for me, but it started something that would eventually change my life.
About 3 years later, I decided I wanted to look into programming again. I wanted a more structured language, so that I could eventually make the move to C#. Zach's friend Brad told me that I should check out Python. He said it was made to be read easily, was object-oriented, and was block structured, so it would be relatively easy to pick up on. I started messing with it, and loved it. It was really cool. I did a few hello world apps and then started messing with the TCL/TK widgets to create console-like applications. It was pretty fun.
About that time, I got a job working for my current company ( Clearwire ). I started as basic tech support. When I came on board, the company was a pretty small start-up company, and didn't have a lot of tools in place. I noticed that the process to notate a customer's account was very time consuming and not user-friendly, so I decided to make an application to help me do that. I wrote a very simple application in Python, using TCL/TK widgets to be my GUI. I didn't want to violate IT policy by installing Python on the machine, so at home, I used an application to compile Python into an executable and brought the executable to work with me the next day.
I began to notice that the application actually decreased my call handle time, which was awesome. A co-worker noticed the application and told upper management that they should check it out. Upper management looked at it, and thought it was cool. They even had plans to talk to IT to make the executable a standard in all the images for tech support partners.
Around this time, there was only one programmer for all of care. I'll call him John because I'm not sure he wants his name posted all over the internet ;P. So, John was tasked with finding someone else to help him do the programming for care because his work load was too intensive for him to handle by himself. The company was a start-up, so the demand on new tools was extremely high.
John interviewed me and two other candidates. During my interview, he asked me if I had any web application programming experience, to which I replied, "Well, I've messed around with basic HTML and CSS on my MySpace page, but other than that, no. I've only barely dabbled in Perl and Python." I walked out of that interview having completely bombed because I did not have the experience for what he needed.
Later on during the day, I approached John and told him that I knew I had bombed the interview, but rather than to go on just that, he should give me a chance to prove myself. See, I have a pretty high learning curve -- I pick up on things pretty quick, and I am able to think my way through programming logic, which is the part of programming that is the hardest, in my opinion.
He agreed, and he said "You know that application you created to help you document the calls you take? I want you to make that into a working web application by the end of the day." He sent me some example code to get me started. The basics on how to connect to a DB in ASP Classic, and a JS example on AJAX, and told me to do the rest. He didn't care if it was super pretty; he just wanted it to work.
I worked as hard as I could, Googling my butt off. Testing, debugging, testing, debugging, until I finally had a working application. I even managed to have the application talk to our documentation application and have it successfully post notes to the customer's account!
It had errors here and there, it was not efficient at all, and had a ton of overhead, but he saw the potential that I had-- I had learned enough ASP Classic, JavaScript, and SQL to make a semi-working application in less than 8 hours.
I wound up getting moved over into the programming position, and have been doing web application development for care for about 2 and a half years now.
Well, now that you know how I got started doing what I do, let me tell you why I love programming.
I love programming for many reasons, that would probably take me forever to type out. This is time I just don't have, so I'll try to limit it as best I can. (These are in no particular order)
1. I love programming because it's a fast-paced environment.
It really keeps me on my toes. As the company's needs change, so do the application's needs. I'm never bored and always busy. It's really fun.
2. There is a lot of awesome documentation.
There are some languages that aren't documented well, but for the most part, there is a lot of really cool and thorough documentation on languages. I'm almost always learning to be more efficient or use better conventions/practices. There's almost always someone out there who has done something I've done but better, and the best part is, they share it with the world! I have a chance to learn from them and implement some of their practices in my code, which makes MY applications run better and MY users happier!
3. The ability to express yourself in your applications.
This might be a little difficult for someone who's not a programmer to understand, but there is a level of elegance that comes with some programming. There's a freedom of expression. Everyone has their own particular style of coding, and it's very interesting to go through and examine different examples that they offer.
I know the intro was long, and the reasons short, and believe me, there are way more reasons why programming is fantastic, but those are just a few of the reasons I love programming. I'm not the best programmer by any means. I'm still young in the community and learning more and more every day, but maybe one day I'll be the guy that people use as examples. One can only hope! "Our rock stars are different from your rock stars" indeed!
I'll open this up to the floor, as well-- what are some reasons you love programming?
So, I started dabbling in programming probably about 6 years ago. My friend, Zach, told me about it, and it peaked my interest. I thought it sounded fun. I was a little intimidated by the strict-typed object-oriented C#, so I decided I wanted to start with a scripting language that had "flexibility", so I started programming in Perl, haha.
I loved the idea that it was super flexible, and that I could say "Do it", and Perl would usually always comply.
I didn't use Perl too much. I made a few hello world applications, and my biggest project was a D&D character roller, haha. I eventually dropped Perl and took a break from programming. The language just wasn't for me, but it started something that would eventually change my life.
About 3 years later, I decided I wanted to look into programming again. I wanted a more structured language, so that I could eventually make the move to C#. Zach's friend Brad told me that I should check out Python. He said it was made to be read easily, was object-oriented, and was block structured, so it would be relatively easy to pick up on. I started messing with it, and loved it. It was really cool. I did a few hello world apps and then started messing with the TCL/TK widgets to create console-like applications. It was pretty fun.
About that time, I got a job working for my current company ( Clearwire ). I started as basic tech support. When I came on board, the company was a pretty small start-up company, and didn't have a lot of tools in place. I noticed that the process to notate a customer's account was very time consuming and not user-friendly, so I decided to make an application to help me do that. I wrote a very simple application in Python, using TCL/TK widgets to be my GUI. I didn't want to violate IT policy by installing Python on the machine, so at home, I used an application to compile Python into an executable and brought the executable to work with me the next day.
I began to notice that the application actually decreased my call handle time, which was awesome. A co-worker noticed the application and told upper management that they should check it out. Upper management looked at it, and thought it was cool. They even had plans to talk to IT to make the executable a standard in all the images for tech support partners.
Around this time, there was only one programmer for all of care. I'll call him John because I'm not sure he wants his name posted all over the internet ;P. So, John was tasked with finding someone else to help him do the programming for care because his work load was too intensive for him to handle by himself. The company was a start-up, so the demand on new tools was extremely high.
John interviewed me and two other candidates. During my interview, he asked me if I had any web application programming experience, to which I replied, "Well, I've messed around with basic HTML and CSS on my MySpace page, but other than that, no. I've only barely dabbled in Perl and Python." I walked out of that interview having completely bombed because I did not have the experience for what he needed.
Later on during the day, I approached John and told him that I knew I had bombed the interview, but rather than to go on just that, he should give me a chance to prove myself. See, I have a pretty high learning curve -- I pick up on things pretty quick, and I am able to think my way through programming logic, which is the part of programming that is the hardest, in my opinion.
He agreed, and he said "You know that application you created to help you document the calls you take? I want you to make that into a working web application by the end of the day." He sent me some example code to get me started. The basics on how to connect to a DB in ASP Classic, and a JS example on AJAX, and told me to do the rest. He didn't care if it was super pretty; he just wanted it to work.
I worked as hard as I could, Googling my butt off. Testing, debugging, testing, debugging, until I finally had a working application. I even managed to have the application talk to our documentation application and have it successfully post notes to the customer's account!
It had errors here and there, it was not efficient at all, and had a ton of overhead, but he saw the potential that I had-- I had learned enough ASP Classic, JavaScript, and SQL to make a semi-working application in less than 8 hours.
I wound up getting moved over into the programming position, and have been doing web application development for care for about 2 and a half years now.
Well, now that you know how I got started doing what I do, let me tell you why I love programming.
I love programming for many reasons, that would probably take me forever to type out. This is time I just don't have, so I'll try to limit it as best I can. (These are in no particular order)
1. I love programming because it's a fast-paced environment.
It really keeps me on my toes. As the company's needs change, so do the application's needs. I'm never bored and always busy. It's really fun.
2. There is a lot of awesome documentation.
There are some languages that aren't documented well, but for the most part, there is a lot of really cool and thorough documentation on languages. I'm almost always learning to be more efficient or use better conventions/practices. There's almost always someone out there who has done something I've done but better, and the best part is, they share it with the world! I have a chance to learn from them and implement some of their practices in my code, which makes MY applications run better and MY users happier!
3. The ability to express yourself in your applications.
This might be a little difficult for someone who's not a programmer to understand, but there is a level of elegance that comes with some programming. There's a freedom of expression. Everyone has their own particular style of coding, and it's very interesting to go through and examine different examples that they offer.
I know the intro was long, and the reasons short, and believe me, there are way more reasons why programming is fantastic, but those are just a few of the reasons I love programming. I'm not the best programmer by any means. I'm still young in the community and learning more and more every day, but maybe one day I'll be the guy that people use as examples. One can only hope! "Our rock stars are different from your rock stars" indeed!
I'll open this up to the floor, as well-- what are some reasons you love programming?
Subscribe to:
Posts (Atom)
Subscribe To
Posts
All Comments