Move Over, AJAX, ARAX Is Here
2008-06-05
Microsoft promotes Asynchronous Ruby and XML development.
Move over, AJAX; Microsoft is pushing a different scenario, known as Asynchronous Ruby and XML, or ARAX.
At the RailsConf conference for Ruby on Rails developers in Portland, Ore., on May 30, John Lam, creator of the IronRuby project at Microsoft, told eWEEK that as Microsoft’s Silverlight rich Internet application environment takes off it will provide Ruby developers with a way to deliver AJAX (Asynchronous JavaScript and XML)-style applications without having to use JavaScript.
“If you’re a Ruby programmer and you like Ruby as a language, context-switching into JavaScript is just something you have to do,” Lam said. “It’s a tax. You’re trading productivity away arbitrarily because that’s just what runs in the browser. And it’s much more interesting when you can run the same language on both sides [the client and the server] so you don’t have to do that context switch.”
In essence, using ARAX, Ruby developers would not have to go through the machinations of using something like the RJS (Ruby JavaScript) utility, where they write Ruby code and RJS generates JavaScript code to run on the client, Lam said. “Sure, you could do it that way, but then at some point you might have to add some JavaScript code that adds some custom functionality on the client yourself,” he said. “So there’s always that sense of, ‘Now I’m in another world. And wouldn’t it be nice if I have this utility class I wrote in Ruby…’ Today if I want to use it in the browser I have to port it to JavaScript. Now I can just run it in the browser.”
According to Lam, the scenario is that people agree that HTML and CSS (Cascading Style Sheets) are standard. “It’s a known thing and people understand this technology,” Lam said. “The part that [is important], at least as far as Rails programmers are concerned with, is they would like to be able to do some Ruby on the client. JavaScript is no longer the ugly stepchild that it used to be, but it’s quirky in certain ways. That’s not to say that Ruby isn’t, but Ruby has more ‘oohs and ahs’ about it than JavaScript does.”
Moreover, “If we do our jobs right and we get Silverlight to play very widely, then all of a sudden for folks that are interested in doing some ARAX, they can. They have to ask, Do we want to take a dependency on this thing? It’s pretty brain-dead to take a dependency on Flash, because Flash is everywhere already. So this becomes a more compelling scenario over time,” he said, noting that as Silverlight adoption grows the opportunity for ARAX development increases.
Ben Galbraith, co-founder of Ajaxian.com, said of ARAX: “If this is about using Silverlight to host client-side browser scripting in Ruby, it’s definitely an appealing notion, but the problem will always be about Silverlight being a Microsoft technology.”
Indeed, Galbraith said, “As long as Windows/Office dominates Microsoft’s balance sheet, these cross-platform Microsoft plays always feel a bit like the story of the boy who upon encountering a rattlesnake picks it up after it promises not to hurt him, upon which the snake promptly bites. After the boy protests, the snake says: ‘You knew what I was when you picked me up.’ No matter what capabilities Silverlight may have, I think most of us in the community simply wouldn’t dream of embracing architectures dependent on Microsoft’s goodwill to support other OS vendors.”
Dion Almaer, the other co-founder of Ajaxian.com, said, “It is interesting to note that you have been able to use JRuby to run Ruby in the browser for quite some time … IronRuby is great. Getting more languages into the browser is great.”
In a blog post, Troy Taft, principal consultant and founder of Troy Taft Consulting, a software development firm, said: “Silverlight and the plug-in RIA wars … caught me by surprise. I didn’t expect Ruby to have a chance at the client. This may make ARAX become more popular than AJAX because you can actually write client-based applications in Silverlight with Ruby in the near future if everything goes well.”
And although Taft (no relation to this reporter) said he considers himself a “JavaScript promoter,” he wrote: “Why do I think that Ruby is better than JavaScript? Mostly because it expresses objects more respectably and it has a cleaner syntax that works in an obvious way to me as developer. This makes the code very readable and easy to use.”
Meanwhile, in a session at RailsConf, Lam showed IronRuby running Ruby on Rails code.
“Our goal was to show that Rails guys could use Silverlight as well,” Lam said. “And if you wanted to use Ruby to do some HTML stuff, if you want to do ARAX on the client, awesome. Knock yourself out.”
With IronRuby, Lam said he demonstrated that Microsoft could dispatch simple Rails requests. “So we can dispatch these static page requests,” he said. “We showed some dynamic stuff happening—we demonstrated we could dispatch to a controller, which will render using a view. And then we showed we could use ActiveRecord to round-trip from SQL Server and return like a single row. So we could demonstrate we could go through the Active Record path. So we can read from database, we can create databases; I don’t think we can update or delete or any of that stuff yet. But that’s coming. This was a demonstration of our commitment to building a Ruby that runs real Ruby programs.”
Lam said he is under no illusion that Rails developers will move in droves to IronRuby.
“Look around at the Rails conference, everybody’s carrying a Mac here,” Lam said. “And this community is a very ‘Unix-y’ community. There are just no if, ands or buts about it. So for us coming here and showing IronRuby running Rails, we weren’t under any illusions that people would convert to us simply because of that. So what we wanted to show was something new, something different. We allow people to run Ruby in the browser in a cross-platform way with a very lightweight download.”
And IronRuby’s support for Ruby on Rails will only get better as the team has more time to work on it, Lam said. Already, he said, he believes IronRuby is further along in its Rails support than either the JRuby or Rubinius projects were at the point when the same amount of time had been put into their efforts.
Ruby on Rails creator David Heinemeier Hansson offered praise for the IronRuby effort.
“It’s great to see Microsoft making progress on IronRuby,” Hansson said. “Just like JRuby provides people who are stuck with an inventory of Java infrastructure and programs an easy way into Ruby, so does IronRuby for those who are still sitting on a Microsoft stack.”
He added, “As with JRuby, though, I don’t expect a lot of Ruby programmers with no existing connection to Microsoft to go gaga over it.”
Filed under: Uncategorized | Leave a Comment
Tags: Technology News
By Richard Casselberry
June 02, 2008
On MSN the other day, I noticed an article called “75 skills every man should master.” It included some skills I have and some I don’t. For example, I can tie a knot and hammer a nail, but frankly I can’t recite a poem from memory, and bow ties still confuse me.
It was an interesting read and made me realize I could be more well-rounded than I am. To be honest, we all could be.
So in the spirit of personal growth, I developed a list of skills every IT person should have.
1. Be able to fix basic PC issues. These can be how to map a printer, back up files, or add a network card. You don’t need to be an expert and understand how to overclock a CPU or hack the registry, but if you work in IT, people expect you to be able to do some things.
2. Work the help desk. Everyone, from the CIO to the senior architect, should be able to sit down at the help desk and answer the phones. Not only will you gain a new appreciation for the folks on the phones, but you will also teach them more about your process and avoid escalations in the future.
3. Do public speaking. At least once, you should present a topic to your peers. It can be as simple as a five-minute tutorial on how IM works, but being able to explain something and being comfortable enough to talk in front of a crowd is a skill you need to have. If you are nervous, partner with someone who is good at it, or do a roundtable. This way, if you get flustered, someone is there to cover for you.
4. Train someone. The best way to learn is to teach.
5. Listen more than you speak. I very rarely say something I didn’t already know, but I often hear other people say things and think, “Darn, I wish I knew that last week.”
6. Know basic networking. Whether you are a network engineer, a help desk technician, a business analyst, or a system administrator, you need to understand how networks work and simple troubleshooting. You should understand DNS and how to check it, as well as how to ping and trace-route machines.
7. Know basic system administration. Understand file permissions, access levels, and why machines talk to the domain controllers. You don’t need to be an expert, but knowing the basics will avoid many headaches down the road.
8. Know how to take a network trace. Everyone in IT should be able to fire up wireshark, netmon, snoop, or some basic network capturing tool. You don’t need to understand everything in it, but you should be able to capture it to send to a network engineer to examine.
9. Know the difference between latency and bandwidth. Latency is the amount of time to get a packet back and forth; bandwidth is the maximum amount of data a link can carry. They are related, but different. A link with high-bandwidth utilization can cause latency to go higher, but if the link isn’t full, adding more bandwidth can’t reduce latency.
10. Script. Everyone should be able to throw a script together to get quick results. That doesn’t mean you’re a programmer. Real programmers put in error messages, look for abnormal behavior, and document. You don’t need to do that, but you should be able to put something together to remove lines, send e-mail, or copy files.
11. Back up. Before you do anything, for your own sake, back it up.
12. Test backups. If you haven’t tested restoring it, it isn’t really there. Trust me.
13. Document. None of the rest of us wants to have to figure out what you did. Write it down and put it in a location everyone can find. Even if it’s obvious what you did or why you did it, write it down.
14. Read “The Cuckoo’s Egg.” I don’t get a cut from Cliff Stoll (the author), but this is probably the best security book there is — not because it is so technical, but because it isn’t.
15. Work all night on a team project. No one likes to do this, but it’s part of IT. Working through a hell project that requires an all-nighter to resolve stinks, but it builds very useful camaraderie by the time it is done.
16. Run cable. It looks easy, but it isn’t. Plus, you will understand why installing a new server doesn’t really take five minutes — unless, of course, you just plug in both ends and let the cable fall all over the place. Don’t do that — do it right. Label all the cables (yes, both ends), and dress them nice and neat. This will save time when there’s a problem because you’ll be able to see what goes where.
17. You should know some energy rules of thumb. For example: A device consuming 3.5kW of electricity requires a ton of cooling to compensate for the heat. And I really do mean a ton, not merely “a lot.” Note that 3.5kW is roughly what 15 to 20 fairly new 1U and 2U servers consume. One ton of cooling requires three 10-inch-round ducts to handle the air; 30 tons of air requires a duct measuring 80 by 20 inches. Thirty tons of air is a considerable amount.
18. Manage at least one project. This way, the next time the project manager asks you for a status, you’ll understand why. Ideally, you will have already sent the status report because you knew it would be asked for.
19. Understand operating costs versus capital projects. Operating costs are the costs to run the business. Capital equipment is made of assets that can have their cost spread over a time period — say, 36 months. Operating costs are sometimes better, sometimes worse. Know which one is better — it can make a difference between a yes and no.
20. Learn the business processes. Being able to spot improvements in the way the business is run is a great technique for gaining points. You don’t need to use fancy tools; just asking a few questions and using common sense will serve you well.
21. Don’t be afraid to debate something you know is wrong. But also know when to stop arguing. It’s a fine line between having a good idea and being a pain in the ass.
22. If you have to go to your boss with a problem, make sure you have at least one solution.
23. There is no such thing as a dumb question, so ask it … once. Then write down the answer so that you don’t have to ask it again. If you ask the same person the same question more than twice, you’re an idiot (in their eyes).
24. Even if it takes you twice as long to figure something out on your own versus asking someone else, take the time to do it yourself. You’ll remember it longer. If it takes more than twice as long, ask.
25. Learn how to speak without using acronyms.
26. IT managers: Listen to your people. They know more than you. If not, get rid of them and hire smarter people. If you think you are the smartest one, resign.
27. IT managers: If you know the answer, ask the right questions for someone else to get the solution; don’t just give the answer. This is hard when you know what will bring the system back up quickly and everyone in the company is waiting for it, but it will pay off in the long run. After all, you won’t always be available.
28. IT managers: The first time someone does something wrong, it’s not a mistake — it’s a learning experience. The next time, though, give them hell. And remember: Every day is a chance for an employee to learn something else. Make sure they learn something valuable versus learning there’s a better job out there.
29. IT managers: Always give people more work than you think they can handle. People will say you are unrealistic, but everyone needs something to complain about anyway, so make it easy. Plus, there’s nothing worse than looking at the clock at 2 p.m. and thinking, “I’ve got nothing to do, but can’t leave.” This way, your employees won’t have that dilemma.
30. IT managers: Square pegs go in square holes. If someone works well in a team but not so effectively on their own, keep them as part of a team.
obtained from:here
Filed under: Uncategorized | 1 Comment
Tags: Uncategorized
-
Recent Comments
sameer on An IT manager’s guide on… jinal on A Map for .net Framework … jinal on A Map for .net Framework … Tarak on Post from The MS Word 2007… It… Tarak on Post from The MS Word 2007… It…
