Friday, June 5, 2009
Workshop 8
1. List what you consider to be the three strengths of Ruby on Rails workshop series.
We consider the 3 strengths to be:
• It uses ruby, which is an emerging new language for web development. The first strength, even though very obvious, we feel that it needs to be expressed. The use of ruby as a development language means that for most of us we will be learning something new. Because this is a master class, most of us have already done some web programming class in the past mostly using PHP or Java (I myself have done 4 classes involving the use of Java, and 2 classes with PHP). The use of Ruby instead of the more popular languages means that we are not repeating and re-learning the same thing again in a different environment.
• The workshop is made in a logical sequence. The Ruby on Rails workshop series was made in a logical sequence, for example, it started by giving a simple task of downloading and installing the Ruby on Rails, along with useful hints. And it developed from there on to more advance learning topics. This structure has made it very easy for students to follow the workshop.
• The workshop series included a lot of coding example. For most of us (or for me at least), the easiest way to learn a new programming language is by using examples, long and detailed explanation would not work as effectively as a coding sample and a little explanation on the sample. This is because IT is a very broad subject with many ambiguous technical term, to understand something it is easier to when we see it in practice.
2. List what you consider to be the three weaknesses of Ruby on Rails workshop series.
I consider the 3 weaknesses to be:
• The division of member in workshop 6 and 7. in workshop 6 and 7 we were put in to the group of developer and manager. This makes the student to focus on 2 group. We think it is much better if it requires us to work in a big group, that it started from the beginning, not only this will enable better communication but also will make it easier for the lecturers to mark each individual contribution to their own group.
• The workshop 5, 6, 7, 8 came out very late in the semester. For half the semester the students does not know anything about other workshop after workshop 4 this created a confusion of whether or not there will be more workshop. And also it wasted our time when the workshop came out after the semester break while the first assignment is due before the semester break, that created a large gap where we do not know what to do, if the workshop have come out earlier, than we could probably start it early and better manage our time.
• The workshop cover just the basic of Ruby. The workshop leave a lot of thing to be desired, it explains the basic and does not go deeply in to the more advanced topics in ruby. However, we realized that 8 workshop is barely enough to go too deep into learning a new programming language from scratch.
3. List what aspects of Ruby on Rails workshop series that you found to be the most difficult.
The most difficult aspects were:
• The most difficult aspect of the Ruby on Rails workshop is the collaboration. From the earlier workshop up to workshop 5 the collaboration is not that difficult, you only need to collaborate on one group consisting of three people at most. After that at workshop 6 and workshop 7 we suddenly got divided into 2 groups of developer and manager team. And everything change, not only you need to still be working in your own group, you also need to collaborate with other group members. And also since there is only 2 group for this tasks, it create a large number of people in one group which in my personal opinion is not effective, and makes it harder to work together.
4. List what improvement could be made to the Ruby on Rails workshop series.
Improvements I would make:
• One of the improvements that we liked to make for the Ruby on Rails workshop is changing it from a Windows based to a Linux based OS platform. I think this will make it more like they have in the industry, because lets face it, almost nobody in the real world uses a windows machine as a Web server platform unless they are running a .NET Website.
• Another improvement is for the workshop to compare the Ruby sample code with another sample code from a more known Web development language such as PHP or JSP, this will make it easier to understand it, at least for the people who have a web programming background.
• Make some sample and show some website that uses Ruby. The workshop should have put more sample on websites that uses Ruby, not only this will show us what are the Ruby capabilities in the real world but also gives us some idea on what to put in our own work that will make it better.
5. Reflect on your experience with the other Web framework used in this subject: was it effective? How can it be improved? Should other Web frameworks be used as well or instead of Ruby on Rails?
We think that Ruby on Rails is an appropriate Web framework to be used. This is because we think that Ruby on Rails would be a widely used Web framework in the industry. And for me personally I like learning new technology and development languages, and Ruby, for me is a new technology that I have never got into before, so it is much better than doing the same old thing with Java or PHP.
6. Did the Developer’s or IT managers Team that you joined after workshop 4 have a preference towards using other tools to facilitate collaboration? Comment on the differences between these use of the sub-forum or Interact wiki tools from your experiences in this subject.
The developer’s team do not uses any collaboration tools. However the manager’s team have use the google groups to do their collaboration. They uses the group to communicate with each other and work together. However, they still mostly uses email to do their collaboration, this is because it is easier to use email to send files then using the google groups, and the email can have more specification on who receive what information, which is something that is hard to do using the google groups.
7. Further comments:
All in all, Ruby on Rails workshop series have been a good learning experience for the students, although it is not perfect in any way. However this is a good thing, considering how well this workshop have been, the fact that it can still get better is really a good news for the next batch of students that will be taking this class in the future.
We consider the 3 strengths to be:
• It uses ruby, which is an emerging new language for web development. The first strength, even though very obvious, we feel that it needs to be expressed. The use of ruby as a development language means that for most of us we will be learning something new. Because this is a master class, most of us have already done some web programming class in the past mostly using PHP or Java (I myself have done 4 classes involving the use of Java, and 2 classes with PHP). The use of Ruby instead of the more popular languages means that we are not repeating and re-learning the same thing again in a different environment.
• The workshop is made in a logical sequence. The Ruby on Rails workshop series was made in a logical sequence, for example, it started by giving a simple task of downloading and installing the Ruby on Rails, along with useful hints. And it developed from there on to more advance learning topics. This structure has made it very easy for students to follow the workshop.
• The workshop series included a lot of coding example. For most of us (or for me at least), the easiest way to learn a new programming language is by using examples, long and detailed explanation would not work as effectively as a coding sample and a little explanation on the sample. This is because IT is a very broad subject with many ambiguous technical term, to understand something it is easier to when we see it in practice.
2. List what you consider to be the three weaknesses of Ruby on Rails workshop series.
I consider the 3 weaknesses to be:
• The division of member in workshop 6 and 7. in workshop 6 and 7 we were put in to the group of developer and manager. This makes the student to focus on 2 group. We think it is much better if it requires us to work in a big group, that it started from the beginning, not only this will enable better communication but also will make it easier for the lecturers to mark each individual contribution to their own group.
• The workshop 5, 6, 7, 8 came out very late in the semester. For half the semester the students does not know anything about other workshop after workshop 4 this created a confusion of whether or not there will be more workshop. And also it wasted our time when the workshop came out after the semester break while the first assignment is due before the semester break, that created a large gap where we do not know what to do, if the workshop have come out earlier, than we could probably start it early and better manage our time.
• The workshop cover just the basic of Ruby. The workshop leave a lot of thing to be desired, it explains the basic and does not go deeply in to the more advanced topics in ruby. However, we realized that 8 workshop is barely enough to go too deep into learning a new programming language from scratch.
3. List what aspects of Ruby on Rails workshop series that you found to be the most difficult.
The most difficult aspects were:
• The most difficult aspect of the Ruby on Rails workshop is the collaboration. From the earlier workshop up to workshop 5 the collaboration is not that difficult, you only need to collaborate on one group consisting of three people at most. After that at workshop 6 and workshop 7 we suddenly got divided into 2 groups of developer and manager team. And everything change, not only you need to still be working in your own group, you also need to collaborate with other group members. And also since there is only 2 group for this tasks, it create a large number of people in one group which in my personal opinion is not effective, and makes it harder to work together.
4. List what improvement could be made to the Ruby on Rails workshop series.
Improvements I would make:
• One of the improvements that we liked to make for the Ruby on Rails workshop is changing it from a Windows based to a Linux based OS platform. I think this will make it more like they have in the industry, because lets face it, almost nobody in the real world uses a windows machine as a Web server platform unless they are running a .NET Website.
• Another improvement is for the workshop to compare the Ruby sample code with another sample code from a more known Web development language such as PHP or JSP, this will make it easier to understand it, at least for the people who have a web programming background.
• Make some sample and show some website that uses Ruby. The workshop should have put more sample on websites that uses Ruby, not only this will show us what are the Ruby capabilities in the real world but also gives us some idea on what to put in our own work that will make it better.
5. Reflect on your experience with the other Web framework used in this subject: was it effective? How can it be improved? Should other Web frameworks be used as well or instead of Ruby on Rails?
We think that Ruby on Rails is an appropriate Web framework to be used. This is because we think that Ruby on Rails would be a widely used Web framework in the industry. And for me personally I like learning new technology and development languages, and Ruby, for me is a new technology that I have never got into before, so it is much better than doing the same old thing with Java or PHP.
6. Did the Developer’s or IT managers Team that you joined after workshop 4 have a preference towards using other tools to facilitate collaboration? Comment on the differences between these use of the sub-forum or Interact wiki tools from your experiences in this subject.
The developer’s team do not uses any collaboration tools. However the manager’s team have use the google groups to do their collaboration. They uses the group to communicate with each other and work together. However, they still mostly uses email to do their collaboration, this is because it is easier to use email to send files then using the google groups, and the email can have more specification on who receive what information, which is something that is hard to do using the google groups.
7. Further comments:
All in all, Ruby on Rails workshop series have been a good learning experience for the students, although it is not perfect in any way. However this is a good thing, considering how well this workshop have been, the fact that it can still get better is really a good news for the next batch of students that will be taking this class in the future.
Thursday, June 4, 2009
Workshop 8 (Engin Sahinel)
1. The three strengths of Ruby on Rails workshop series are;
- I could find out MVC design;
- I could gain basic level experience on building a web site for e-commerce;
- I could find out importance of team work and ruby on rails which is the easiest and fastest way to develop a web site, through these workshop series.
2. The three weaknesses of Ruby on Rails workshop series are;
- All workshop questions required too much documentation;
- Sharing our experiences part was helpful but it would not be must.
- Due to scripting language disadvantages, I spent too much time to find out my mistakes while i was developing.
3. The most difficult aspects were:
Finding out expected results of the workshop questions and learning a new scripting language was quite difficult for me. I wish to learn a new generation web site programming language such as, PHP or ASP.
4. Improvements I would make include:
At the beginning, a well designed tutorial should be prepared for beginners. For example, it can include how to install and configure software then how to develop a program using its API. In addition, instead of too basic examples, we should work on real world applications.
5. Comments for Web framework used in these workshops;
As I stated above, I prefer to study on mostly used web frameworks like J2EE and .NET, rather than Rails framework. In addition, instead of 8 workshops, 1 or 2 big real life projects that should run on the other popular web frameworks, can be assigned to us. Because when we look for a job, we can meet the industry requirements.
6. Comments on other tools to facilitate collaboration
I was studying as a developer after workshop 4. During this semester, we used google group, It provided to discuss on our problems and let us to share our positive or negative experiences. However, except our lecturer, there were no experienced person about Ruby on Rails applications. For that reason, usually we needed to get his help and when I got trouble during my developing processes, I asked to him directly or researched on google books.
7. Further comments to add?
In my opinion, social networking should not be as a marking criteria. In conclusion, although I have some concerns about web framework, I am happy to learn new programming language and web programming techniques. I want to thank Peter for his patience and help.
Workshop 7 - DEVELOPER’S THREAD
In this part of the workshop 7, we are going to examine the various platforms/software tools used for deployment such as UNIX environment suggested in the Discussion Notes, Mongrel or Mongrel cluster, Nginx, Subversion or Capistrano (during development stage), JRuby in the Java environment.
So far, we have developed a Ruby on Rails application. Due to, rails is a server independent language, you can focus on development rather than deployment. Therefore, we are going to introduce ways of deploying ruby on rails applications and deploying JRuby on Rails applications.
Deploying Ruby on Rails
Most Rails organizations use Capistrano to handle the actual deployment. On the other hand there are some ways to handle deploying. These are;
WEBrick
The simplest way or handling a Rails application is to handle it the same way you do when developing it: start a WEBrick server and be done with it. This solution is probably one of the worst ones. WEBrick is highly useful for testing your application during development. It’s small, it’s pure Ruby, and it's already installed on all Ruby machines. This makes it straightforward to handle. On the other hand, it’s written in pure Ruby, which means the performance could be much better. In fact, WEBrick is slow. It also has a tendency to hang and stop responding after a while. For these reasons, it works fine for short-lived development runs, and possibly also for running automated test suites. However, for real-world deployment, you need another solution.
Mongrel
Mongrel is widely believed to be much faster than WEBrick, and is also a good standalone library for creating smaller web applications. In many places, Mongrel has replaced WEBrick as the server of choice for Rails development. Because it is fast to start and easy to configure in standalone mode, this means you get a better and faster web server for your Rails development, all for free. For smaller web applications, you can also use Mongrel in standalone mode to serve Rails applications in production. If you know that the site traffic will be small, and there is no huge demand on scalability. Mongrel is usually good enough. It's also easy to get going; you can just start it with script/server and it runs accurately.
Pack of Mongrels
To solve the scalability problem with Mongrel, the standard solution is to deploy a “pack of Mongrels. This lets you start several Mongrel instances on the same machine with consecutive port numbers. The other side of this is usually a load balancer or some sort. The two most common real world deployments use Apache and Pound. The beauty or this solution is that if your needs grow, or if your site gets popular, you can just add more Mongrel instances, on the same or another computer. The Apache front end then load balances over all the new Mongrels with a reloading of the configuration tile (Bini, 2007, p. 200).
Deploying JRuby on Rails
JRuby is a Java implementation of the Ruby Programming Language. It is tightly integrated with Java to allow the embedding of the interpreter into any Java application with two-way access between the Java and Ruby code (Edelson, & Henry, 2008, p. 182). As it is mentioned above section, there are some variations on how to deploy a Rails application with Ruby framework. In addition to this there are some new possibilities using with JRuby.
WEBrick
Using WEBrick during development usually works well with JRuby. However, for deploymen, it suffers from exactly the same problems as WEBrick on regular Ruby: it’s slow and unstable, having a tendency to stop responding. Except for the most noncritical applications, you shouldn’t use WEBrick for deployment in JRuby.
Mongrel
Mongrel has a native extension written in C, which is one of the reasons its faster than WEBrick. This extension has been ported to Java, which means you can use Mongrel from JRuby. In addition, JRuby on Rails application has many advantages with Mongrel as regular Ruby.
Retty
Retty is a simple Rails plug-in, based on the Java web containers Jetty and GoldSpike. When you’ve installed the plug-in, you can start a Jetty server that handles Rails requests with this command: "jruby -s rake retty:run" Jetty is a small and fast web container, and running smaller Rails applications in this way makes for the best parts or a Rails application and embedding a real Java web server. You can use Retty for deploying smaller standalone applications without a problem, and It can also easily be used in a pack.
As a result, you can use Mongrel for smaller applications, but when your web page has high traffic rates, you need to use a real load balancer in front of them. The problem with this approach on the Java platform is that you don’t want to start several JVMs, because they are slow to start and resource heavy. JRuby supports the option of starting a JRuby server and spreads new runtimes for each request that arrives on that port. By using that capability, you can start several Mongrel instances in the same JVM (Bini, 2007, p. 205).
Can you get the OTBS Running in production mode as a minimal production server?
In order to have a minimal production server, we are going to use Mongrel Web Server for OTBS application. As it is stated above paragraph, Mongrel is quite efficient for this application at the beginnig. Then, Sqlite database is goning to be used. After these two significant part is installed to the production server, they are needed to configured properly for your application (OTBS). After all processes are completed accurately, the server can publish your application and everyone can access your web application all over the world.
References
Bini, O. (2007). Practical JRuby on Rails Web 2.0 Projects: Bringing Ruby on Rails to the Java Platform. Apress.
Edelson, J., & Henry, L. (2008). JRuby Cookbook (First ed.). O'Reilly Media.
So far, we have developed a Ruby on Rails application. Due to, rails is a server independent language, you can focus on development rather than deployment. Therefore, we are going to introduce ways of deploying ruby on rails applications and deploying JRuby on Rails applications.
Deploying Ruby on Rails
Most Rails organizations use Capistrano to handle the actual deployment. On the other hand there are some ways to handle deploying. These are;
WEBrick
The simplest way or handling a Rails application is to handle it the same way you do when developing it: start a WEBrick server and be done with it. This solution is probably one of the worst ones. WEBrick is highly useful for testing your application during development. It’s small, it’s pure Ruby, and it's already installed on all Ruby machines. This makes it straightforward to handle. On the other hand, it’s written in pure Ruby, which means the performance could be much better. In fact, WEBrick is slow. It also has a tendency to hang and stop responding after a while. For these reasons, it works fine for short-lived development runs, and possibly also for running automated test suites. However, for real-world deployment, you need another solution.
Mongrel
Mongrel is widely believed to be much faster than WEBrick, and is also a good standalone library for creating smaller web applications. In many places, Mongrel has replaced WEBrick as the server of choice for Rails development. Because it is fast to start and easy to configure in standalone mode, this means you get a better and faster web server for your Rails development, all for free. For smaller web applications, you can also use Mongrel in standalone mode to serve Rails applications in production. If you know that the site traffic will be small, and there is no huge demand on scalability. Mongrel is usually good enough. It's also easy to get going; you can just start it with script/server and it runs accurately.
Pack of Mongrels
To solve the scalability problem with Mongrel, the standard solution is to deploy a “pack of Mongrels. This lets you start several Mongrel instances on the same machine with consecutive port numbers. The other side of this is usually a load balancer or some sort. The two most common real world deployments use Apache and Pound. The beauty or this solution is that if your needs grow, or if your site gets popular, you can just add more Mongrel instances, on the same or another computer. The Apache front end then load balances over all the new Mongrels with a reloading of the configuration tile (Bini, 2007, p. 200).
Deploying JRuby on Rails
JRuby is a Java implementation of the Ruby Programming Language. It is tightly integrated with Java to allow the embedding of the interpreter into any Java application with two-way access between the Java and Ruby code (Edelson, & Henry, 2008, p. 182). As it is mentioned above section, there are some variations on how to deploy a Rails application with Ruby framework. In addition to this there are some new possibilities using with JRuby.
WEBrick
Using WEBrick during development usually works well with JRuby. However, for deploymen, it suffers from exactly the same problems as WEBrick on regular Ruby: it’s slow and unstable, having a tendency to stop responding. Except for the most noncritical applications, you shouldn’t use WEBrick for deployment in JRuby.
Mongrel
Mongrel has a native extension written in C, which is one of the reasons its faster than WEBrick. This extension has been ported to Java, which means you can use Mongrel from JRuby. In addition, JRuby on Rails application has many advantages with Mongrel as regular Ruby.
Retty
Retty is a simple Rails plug-in, based on the Java web containers Jetty and GoldSpike. When you’ve installed the plug-in, you can start a Jetty server that handles Rails requests with this command: "jruby -s rake retty:run" Jetty is a small and fast web container, and running smaller Rails applications in this way makes for the best parts or a Rails application and embedding a real Java web server. You can use Retty for deploying smaller standalone applications without a problem, and It can also easily be used in a pack.
As a result, you can use Mongrel for smaller applications, but when your web page has high traffic rates, you need to use a real load balancer in front of them. The problem with this approach on the Java platform is that you don’t want to start several JVMs, because they are slow to start and resource heavy. JRuby supports the option of starting a JRuby server and spreads new runtimes for each request that arrives on that port. By using that capability, you can start several Mongrel instances in the same JVM (Bini, 2007, p. 205).
Can you get the OTBS Running in production mode as a minimal production server?
In order to have a minimal production server, we are going to use Mongrel Web Server for OTBS application. As it is stated above paragraph, Mongrel is quite efficient for this application at the beginnig. Then, Sqlite database is goning to be used. After these two significant part is installed to the production server, they are needed to configured properly for your application (OTBS). After all processes are completed accurately, the server can publish your application and everyone can access your web application all over the world.
References
Bini, O. (2007). Practical JRuby on Rails Web 2.0 Projects: Bringing Ruby on Rails to the Java Platform. Apress.
Edelson, J., & Henry, L. (2008). JRuby Cookbook (First ed.). O'Reilly Media.
Wednesday, June 3, 2009
Workshop 6 - DEVELOPER’S THREAD
This workshop requires development for the Online Taxi Booking Service. The main issue is about adding user session feature to the OTBS. In order to do user registration and advanced login features from Hartl et al (2008), we need to follow the instructions from Rails Space text book. In this part of the assignment, we are going to apply below steps;
o generate a controller and an action by adding a method(s) to a controller;
o create a view template for each action and to link to actions from views;
o use AJAX to improve the user experience.
After "Modeling users", "Registering users", "Logging in and out"and "Advanced login" chapters that are on the Rails Space book are completed, we have a new online taxi booking service that includes user registration feature.
1. When you type the web address of the OTBS, first page is about login the system.
2. If you try to pass "login" or "register" steps, it insists on you to login first.
3. If you do not have an account, you need to register as shown below.
4. After the successful registration process, you will see the home page that allows the user creating new passenger details, showing all passengers and and showing all destinations.
5. The next figures show that home page after login process.
6. Follwing figures show that error cases and regarding messages. 
o generate a controller and an action by adding a method(s) to a controller;
o create a view template for each action and to link to actions from views;
o use AJAX to improve the user experience.
After "Modeling users", "Registering users", "Logging in and out"and "Advanced login" chapters that are on the Rails Space book are completed, we have a new online taxi booking service that includes user registration feature.
1. When you type the web address of the OTBS, first page is about login the system.
2. If you try to pass "login" or "register" steps, it insists on you to login first.
3. If you do not have an account, you need to register as shown below.
4. After the successful registration process, you will see the home page that allows the user creating new passenger details, showing all passengers and and showing all destinations.
5. The next figures show that home page after login process.
6. Follwing figures show that error cases and regarding messages.
Tuesday, June 2, 2009
Workshop 5 - DEVELOPER’S THREAD
PART A
In this part of the workshop 5, interaction between controller and view, on MVC structure, will be shown. We are going to use ruby on rails development environment to do this.
1. Create the Rails application framework in the projects folder: C:\InstantRails\...\projects\>rails animals
2. Running the application on localhost:3000 using the WeBrick ruby server (or Mongrel as alternative) and access via Web browser at http://localhost:3000/
3. Create the controller to make the application do an action. This is under the controller-action/model-view structure.
Stop the WEBrick server each time you edit Ruby classes and then re-start or refresh the views you are testing. Use the Ruby command below:
>ruby script/generate controller Mammal
The mammal_controller.rb contains just a bare class description:
class MammalController
4. Test the controller by starting the WEBrick server and navaigatibng the browser to http://localhost:3000/mammal Note how the controller name is appended to the end of the URL and that no action resulted because there are no controller methods.
5. Create an action by editing and saving the mammal_controller.rb class in projects\animals\app\controllers using your text editor to add the method below:
class MammalController
6. Start the WEBrick server and browse at http://localhost:3000/mammals/breathe where you will get a “missing template” message since it is missing a view for the breathe method.
Rails is trying to connect the breathe method action of the mammal controller to a view, by using the action’s name – breathe. This view template is created as breathe.rhtml and stored in the \projects\animals\views\mammal directory.
7. Create and save a view in that directory by using a text editor to create a view called breathe.rhtml
8. Try Ruby code and HTML in the action view by using the <%....%>wrapper around the inserted Ruby code.
In this part of the workshop 5, we are going to show using of radio buttons, text box and combo box. In addition to this, you will see how to pass data from a public file to view file through controller.
In this part of the workshop 5, interaction between controller and view, on MVC structure, will be shown. We are going to use ruby on rails development environment to do this.
1. Create the Rails application framework in the projects folder: C:\InstantRails\...\projects\>rails animals
2. Running the application on localhost:3000 using the WeBrick ruby server (or Mongrel as alternative) and access via Web browser at http://localhost:3000/
3. Create the controller to make the application do an action. This is under the controller-action/model-view structure.
Stop the WEBrick server each time you edit Ruby classes and then re-start or refresh the views you are testing. Use the Ruby command below:
>ruby script/generate controller Mammal
The mammal_controller.rb contains just a bare class description:
class MammalController
4. Test the controller by starting the WEBrick server and navaigatibng the browser to http://localhost:3000/mammal Note how the controller name is appended to the end of the URL and that no action resulted because there are no controller methods.
5. Create an action by editing and saving the mammal_controller.rb class in projects\animals\app\controllers using your text editor to add the method below:
class MammalController
6. Start the WEBrick server and browse at http://localhost:3000/mammals/breathe where you will get a “missing template” message since it is missing a view for the breathe method.
Rails is trying to connect the breathe method action of the mammal controller to a view, by using the action’s name – breathe. This view template is created as breathe.rhtml and stored in the \projects\animals\views\mammal directory.
7. Create and save a view in that directory by using a text editor to create a view called breathe.rhtml
8. Try Ruby code and HTML in the action view by using the <%....%>wrapper around the inserted Ruby code.
PART B
In this part of the workshop 5, we are going to show how to pass data from an action to a view.
In this part of the workshop 5, we are going to show how to pass data from an action to a view.
PART C
In this part of the workshop 5, we are going to show using of radio buttons, text box and combo box. In addition to this, you will see how to pass data from a public file to view file through controller.
Subscribe to:
Posts (Atom)