Adobe Flash CS5 Can Export to HTML5 Canvas
Adobe is not in the best position it has ever been, as its massively popular Flash platform is getting attacked from all sides. Apple is leading the charge, and the weapon it's using against it is HTML5. The proposed web standard can do many of the things Flash does, offering developers an... [View Full Article]
Twitter toys with sending ads to clients
In the history of anything whatsoever, timing is rarely, if ever, coincidental. More often these days, however, the strategy behind it looks confusing. Just days before it's scheduled to hold its developers conference in San Francisco (tomorrow and Thursday), Twitter revealed that it is in the process of either acquiring or building applications that will compete directly with the Twitter clients these developers will be taught how to build.
On Friday, Twitter revealed it was in the midst of purchasing Tweetie, believed to be the most popular Twitter client for Apple's iPhone. That product will become "Twitter for iPhone." That same day, the service released a Twitter client for BlackBerry; and it's that second event that let developers know, as Arlo Guthrie once put it, that there's a movement.S
Source:BetaNews
On Friday, Twitter revealed it was in the midst of purchasing Tweetie, believed to be the most popular Twitter client for Apple's iPhone. That product will become "Twitter for iPhone." That same day, the service released a Twitter client for BlackBerry; and it's that second event that let developers know, as Arlo Guthrie once put it, that there's a movement.S
Source:BetaNews
10 Reasons why Ruby is better than PHP
I bet you thought I'd never get any more reasons out did ya? Well, today, I'm going to tell you all about IRB and the Rails command line debugger, both of which I use religiously.
One of the great pleasures of using Ruby, apart from the previous three reasons, and of course the following five reasons, is the wonder that is the Interactive Ruby console, or IRB. IRB is an interactive interpreter; which means that instead of processing a file, it processes what you type in during a session. It's a great tool for testing Ruby code, and a great tool for learning Ruby.
Once you have Ruby installed on your computer, you will notice that the
This is the
IRB lets you do things without having to fake out your controller. For example, in PHP, I'm forever using
Each of the above lines will be following by IRB echoing the result. So I can see exactly what is going on, and without me having to echo out data all through my code and to the browser.
This is actually very, very useful, and is a great way to test your code, or in fact any code at all. It's even better if you are a command line freak like me.
What is even better, better (!?) is that Rails also has its own command line interpreter, which is basically an extension of IRB. What makes it a little different, is that when it is started up, it also loads all your Rails code. So you have instant access to your Rails models, which is also very handy. Just cd to your Rails app root, and run:
You are then shown a similar command line prompt to IRB, and can run any part of your Rails app code.
To wrap up reason #4, I want to tell you about one of the best things about developing with Ruby on Rails. It's another extension of IRB, similar to Rails
There are several ways in which you can run your Rails app, but the traditional method is by using the the
Just
Notice I appended a command line flag;
And the command line prompt will sit there blinking at you, waiting for you to load your app in your browser. So don't keep it waiting, open up your browser, and go to
Now we get to the good bit. Open up the code of any of your controllers in your favourite IDE or text editor. Then type the word
Go back to your command line when you started the Rails server, and you will see a bunch of log data, following by what looks like an IRB prompt. That is effectively what it is. You can now type any Ruby code at that prompt, just like you would with IRB or
So instead of having to type echo or print statements throughout your code, and running them through your browser to see the results. You can add the debugger keywork at the point where you want to debug, and use the command line to access your code in real time.
I really hope you got all that, as this feature has saved me hours and hours of time when debugging my code. I can honestly say that it is a life saver. You really should try it out now, or if you're a little impatient, try it out in your browser for instant gratification. You should also check out Amy Hoy's "Secrets of the Rails Console Ninja's".
Thanks again for sticking with me, and hold on to your pants for reason #5 where I will be talking about Modules; Ruby's answer to name spaces. Which will lead me nicely onto another Ruby exclusive: Mixins!
P.S. I really appreciate everyone's comments. Keep them coming.
One of the great pleasures of using Ruby, apart from the previous three reasons, and of course the following five reasons, is the wonder that is the Interactive Ruby console, or IRB. IRB is an interactive interpreter; which means that instead of processing a file, it processes what you type in during a session. It's a great tool for testing Ruby code, and a great tool for learning Ruby.
Once you have Ruby installed on your computer, you will notice that the
ruby command will do the same thing as PHP - it silently waits for a script to be streamed in on stdin. On it's own, that's not particularly friendly, or even that useful. But another command that is installed alongside Ruby, is the irb command. Start up your command line tool of choice, and simply enter these three immortal letters: irb. Then you will see this:This is the
irb prompt. Now all you do is simply type any ruby code, and it will show you the result of each and every expression as it is evaluated. Not sure how a method works, or can't remember the output of a method? Then test it with IRB.IRB lets you do things without having to fake out your controller. For example, in PHP, I'm forever using
echo or CakePHP's debug function to print out some useful info to the browser when debugging my code. But when developing with Ruby, I simply have my trusty IRB prompt ready and waiting for me to inflict world domination.Each of the above lines will be following by IRB echoing the result. So I can see exactly what is going on, and without me having to echo out data all through my code and to the browser.
This is actually very, very useful, and is a great way to test your code, or in fact any code at all. It's even better if you are a command line freak like me.
What is even better, better (!?) is that Rails also has its own command line interpreter, which is basically an extension of IRB. What makes it a little different, is that when it is started up, it also loads all your Rails code. So you have instant access to your Rails models, which is also very handy. Just cd to your Rails app root, and run:
You are then shown a similar command line prompt to IRB, and can run any part of your Rails app code.
To wrap up reason #4, I want to tell you about one of the best things about developing with Ruby on Rails. It's another extension of IRB, similar to Rails
script/console, but is simply genius when debugging your Rails code.There are several ways in which you can run your Rails app, but the traditional method is by using the the
script/server script within your app. When run on the command line, this will start up a small web server, usually run by Webrick or Mongrel. Now I wouldn't recommend this method when running your app in production, as there are much better, and more efficient ways to do so, but I use this all the time when developing or testing my app code.Just
cd to your Rails app root and run this on the command line:Notice I appended a command line flag;
-u. This tells the Rails server to start up in Debug mode. If you use Mongrel, this is what you will see:And the command line prompt will sit there blinking at you, waiting for you to load your app in your browser. So don't keep it waiting, open up your browser, and go to
http://localhost:3000, and you will be shown your Rails app in all its glory.Now we get to the good bit. Open up the code of any of your controllers in your favourite IDE or text editor. Then type the word
debugger within one of your actions. Then go back your browser and navigate to that page. You should the notice that the page does not appear to finish loading. That is because your debugger keyword within the action method, has paused the server until you tell it to continue.Go back to your command line when you started the Rails server, and you will see a bunch of log data, following by what looks like an IRB prompt. That is effectively what it is. You can now type any Ruby code at that prompt, just like you would with IRB or
script/console. But the beauty of this, is that you have access to all the variables and methods at exactly the same point in your code where you placed the debugger keyword.So instead of having to type echo or print statements throughout your code, and running them through your browser to see the results. You can add the debugger keywork at the point where you want to debug, and use the command line to access your code in real time.
I really hope you got all that, as this feature has saved me hours and hours of time when debugging my code. I can honestly say that it is a life saver. You really should try it out now, or if you're a little impatient, try it out in your browser for instant gratification. You should also check out Amy Hoy's "Secrets of the Rails Console Ninja's".
Thanks again for sticking with me, and hold on to your pants for reason #5 where I will be talking about Modules; Ruby's answer to name spaces. Which will lead me nicely onto another Ruby exclusive: Mixins!
P.S. I really appreciate everyone's comments. Keep them coming.
Top 10 Performance Testing Mistakes
1.Incorrect Load Levels
Fix: Improve and focus communications by conducting a one-on-one interview to determine expected “real world” load levels. If the application is already in production, obtain live usage data.
2 Performance Tester Identifying Key Business Processes
Fix: Conduct a one-on-one interview to identify key business processes: mission critical, heavy throughput, dynamic content, and any other business process that causes concern.
3 Too Many Business Processes
Fix: Concentrate on a few, perhaps 6-8, key business processes for performance testing - this is not a functional test.
4 Altering Load Test Objectives
Fix: Develop a complete custom plan with goal load levels, business process steps, transaction names, and acceptable response times. Analyze any missed objectives - stay consistent with the original goals unless there is a compelling reason for change.
5 Late Focus on Performance Testing
Fix: Engage the performance testing team as early as possible in the development life cycle to allow time between executions for a good analysis of the results from the performance tester. Detecting and correcting performance issues early reduces the repair cost.
6 Poor Transaction Naming Convention
Fix: For easier analysis, maintainability, future growth, and possible server consolidation, provide a clear naming convention.
7 Performance Tester Stands Alone
Fix: Let the experts do what they do best. Involve all members of the team: the DBA, Web Server Expert, Application Expert, Developer, etc. Executing a performance test is best done as a team.
8 Not Validating the Execution Transaction Levels
Fix: Validating transaction levels against the test plan after executing a full load test ensures the test presented the desired load to the application.
9 Server Experts Become Bouncy
Fix: If possible, don't bounce the server between test executions. Bouncing the server prior to every test causes the need to rebuild the memory and cache. Memory leaks and other reliability and availability issues will be more easily identified if the server is left untouched.
10 Over-technical on Results Reporting
Fix: Performance testing creates mountains of data that are usually very interesting to technical experts. Ultimately, however, the owners of the application are looking for key performance indicators to make a sound business decision for their application go-live. Create a one-minute overview for managers that concisely conveys the critical data related to application performance.
Fix: Improve and focus communications by conducting a one-on-one interview to determine expected “real world” load levels. If the application is already in production, obtain live usage data.
2 Performance Tester Identifying Key Business Processes
Fix: Conduct a one-on-one interview to identify key business processes: mission critical, heavy throughput, dynamic content, and any other business process that causes concern.
3 Too Many Business Processes
Fix: Concentrate on a few, perhaps 6-8, key business processes for performance testing - this is not a functional test.
4 Altering Load Test Objectives
Fix: Develop a complete custom plan with goal load levels, business process steps, transaction names, and acceptable response times. Analyze any missed objectives - stay consistent with the original goals unless there is a compelling reason for change.
5 Late Focus on Performance Testing
Fix: Engage the performance testing team as early as possible in the development life cycle to allow time between executions for a good analysis of the results from the performance tester. Detecting and correcting performance issues early reduces the repair cost.
6 Poor Transaction Naming Convention
Fix: For easier analysis, maintainability, future growth, and possible server consolidation, provide a clear naming convention.
7 Performance Tester Stands Alone
Fix: Let the experts do what they do best. Involve all members of the team: the DBA, Web Server Expert, Application Expert, Developer, etc. Executing a performance test is best done as a team.
8 Not Validating the Execution Transaction Levels
Fix: Validating transaction levels against the test plan after executing a full load test ensures the test presented the desired load to the application.
9 Server Experts Become Bouncy
Fix: If possible, don't bounce the server between test executions. Bouncing the server prior to every test causes the need to rebuild the memory and cache. Memory leaks and other reliability and availability issues will be more easily identified if the server is left untouched.
10 Over-technical on Results Reporting
Fix: Performance testing creates mountains of data that are usually very interesting to technical experts. Ultimately, however, the owners of the application are looking for key performance indicators to make a sound business decision for their application go-live. Create a one-minute overview for managers that concisely conveys the critical data related to application performance.
James Gosling leaves Oracle
James Gosling, the creator of the Java programming language, has resigned from Oracle, he announced in a blog entry on Friday
Gosling resigned on April 2 and has not yet taken a job elsewhere, he reported.
"As to why I left, it's difficult to answer: just about anything I could say that would be accurate and honest would do more harm than good," he wrote.
Source:www.businessweek.com
Gosling resigned on April 2 and has not yet taken a job elsewhere, he reported.
"As to why I left, it's difficult to answer: just about anything I could say that would be accurate and honest would do more harm than good," he wrote.
Source:www.businessweek.com
Subscribe to:
Posts (Atom)