Pligg CMS 1.2.0 is available. The version adds some important security updates, many bug fixes, optimized code, and a few new features. Some of the changes are listed below in an abbreviated changelog highlighting some of the most important updates. We highly recommend that you update your Pligg CMS website as soon as possible to avoid exploits from previous security holes that have now been patched.

1. Security fixes
2. Exclude disabled users from Top Users
3. Fixed the “Edit user data” admin feature
4. New weight parameter for modules, allowing modules to control what order they are called in.
5. Search groups by group name
6. The Tag Cloud page is now disabled when you have tags turned off site-wide
7. Human check (anti-spam) module fixes
8. Localized a few new phrases
9. Add feature to subtract a value of user score for removing a story vote
10. You can now use PHP in page content.
11. Left open HTML tags in the story content area will now be automatically closed.
12. Users can now select a site language file from their edit profile page. This will only change the Pligg language file, not the content being submitted to the site.

• Streaming
• Reversible Migrations
• Assets Pipeline
• jQuery as the default JavaScript library

Download – http://rubyonrails.org/download

Read more Rails 3.1.0 has been released!

This release includes more than 50 feature enhancements and bug fixes. Some exciting new features include:

• Added a SQL query builder
• Implemented database migration support
• Enhanced support for using plural forms, and upgraded CLDR i18n data to version 1.9
• Improved exception display in Web mode and error display in console mode
• Added support for using anonymous parameters and global options in console commands
• Added support for using X-Sendfile to send files

For the complete list of changes in this release, please see the change log and important feature additions.

PrestaShop v.1.4 alpha 2 has been released on november 15,2010.This new version, real milestone for our software, contains more than 50 new features!

New Features:

Alongside partners’ modules, a lot of new features have been integrated to PrestaShop, for every need and every activity.

* WebService

Ability to communicate more simply (Data Exchange) with third-party players such as logistics, accounting…

* “Catalog” Mode

Ability to disable the price display to transform the store in a catalog

* One page Checkout

Order process on a single page

* Products Comparison

Allows customers to easily compare simultaneously several products

* VAT identification number

Manage the buyer’s intra-community VAT number (UE) during a B2B order, and management of relative taxes

* Delivery Date Module

Indicates a delivery deadline during the order process, in accordance with the Ch??tel law (France)

* Overriding PrestaShop Core

Ability to change and override the core of PrestaShop, creating children objects

* Shipping costs by product

Ability to set different shipping costs depending on the products and their characteristics

* Store Locator

List and locate physical stores on a Google map

* New Tab “Customer Service”

Enable to manage easily interactions with customers, directly from the Back-Office

* New Back-Office design

Two templates are now available, and ability to create new ones

* Location packs

Allow to import, directly from the Back-Office, taxes, states, currencies and languages regarding a specific country

* Customizations mails

Default emails edition and translation of the subject via the Back-Office

* Proxy JavaScript / CSS (Combine Compress & Cache)

Performance enhancement on the Front-Office for a better navigation

* Staging of product pages

Products’ pages preview before publishing them directly from the Front-Office

* Staging of the CMS pages

Preview of CMS pages before publishing them directly from the Front-Office

* Groups’ discount coupon

Ability to apply discounts to specific customers groups

* Choice of a product status

Possibility to define a product as a Web exclusivity and its status to new, used…

* PrestaShop Addons Integration into the Back-Office

PrestaShop Addons modules are now available from the Back-Office

* InnoDB support added

More efficient storage engine than MyISAM

* UPC codes support added

Additional way to identify a product (thanks to UPC codes)

Gallery is open source web based photo album organizer. Gallery gives you an intuitive way to blend photo management seamlessly into your own website whether you’re running a small personal site or a large community site.

Gallery 3.0 means simple, powerful and secure photo management. Upload and manage your photos effortlessly, while creating a beautiful experience for your friends and family. If you’re a developer, you can easily add new features or create your own elegant themes.

This release is code named Santa Fe to commemorate the location of our last team meetup. It was thanks to the generous donations from many of you that we were able to get to the team together and make a big push to move Gallery forward. We had a wonderful time in New Mexico and want to celebrate that milestone of our release.

Download it now!

A web app in 10 minutes using Play! from zenexity on Vimeo.

The Play framework is a clean alternative to bloated Enterprise Java stacks. It focuses on developer productivity and targets RESTful architectures. Play is a perfect companion to agile software development.

The Play framework’s goal is to ease web applications development while sticking with Java.

Play framework 1.0.3 documentation

Download Play Framework

Remember how Facebook used to lumber and strain? And have you noticed how it doesn’t feel slow anymore? That’s because the engineering team pulled off an impressive feat: an in-depth optimization and rewrite project made the site twice as fast.

Robert Johnson, Facebook’s director of engineering and a speaker at the upcoming Velocity and OSCON conferences, discusses that project and its accompanying lessons learned below. Johnson’s insights have broad application — you don’t need hundreds of millions of users to reap the rewards.

Facebook recently overhauled its platform to improve performance. How long did that process take to complete?

Robert Johnson: Making the site faster isn’t something we’re ever really done with, but we did make a big push the second half of last year. It took about a month of planning and six months of work to make the site twice as fast.

What big technical changes were made during the rewrite?

Robert Johnson: The two biggest changes were to pipeline the page content to overlap generation, network, and render time, and to move to a very small core JavaScript library for features that are required on the initial page load.

The pipelining project was called BigPipe, and it streams content back to the browser as soon as it’s ready. The browser can start downloading static resources and render the most important parts of the page while the server is still generating the rest of the page. The new JavaScript library is called Primer.

In addition to these big site-wide projects, we also performed a lot of general cleanup to make everything smaller and lighter, and we incorporated best practices such as image spriting.

Were developers encouraged to work in different ways?

This was one of the trickiest parts of the project. Moving fast is one of our most important values, and we didn’t want to do anything to slow down development. So most of our focus was on building tools to make things perform well when developers do the things that are easiest for them. For example, with Primer, making it easy to integrate and hard to misuse was as important to its design as making it fast.

We also built detailed monitoring of everything that could affect performance, and set up systems to check code before release.

It’s really important that developers be automatically alerted when there’s a problem, instead of developers having to go out of their way for every change. That way, people can continue innovating quickly, and only stop to deal with performance in the relatively unusual case that they’ve caused a problem.

How do you address exponential growth? How do you get ahead of it?

You never get ahead of everything, but you have to keep ahead of most things most of the time. So whenever you go in to make a particular system scale better, you can’t settle for twice as good, you really need to shoot for 10 or 100 times as good. Making something twice as good only buys a few months, and you’re back at it again as soon as you’re done.

In general, this means scaling things by allowing greater federation and parallelism and not just making things more efficient. Efficiency is of course important, too, but it’s really a separate issue.

Two other important things: have good data about how things are trending so you catch problems before you’re in trouble, and test everything you can before you have to rely on it.

In most cases the easiest way for us to test something new is to put it in production for a small number of users or on a small number of machines. For things that are completely new, we set up “dark launches” that are invisible to the user but mimic the load from the real product as much as possible. For example, before we launched chat we had millions of JavaScript clients connecting to our backend to make sure it could handle the load.

Facebook’s size and traffic aren’t representative of most sites, but are there speed and scaling lessons you’ve learned that have universal application?

The most important one isn’t novel, but it’s worth repeating: scale everything horizontally.

For example, if you had a database for users that couldn’t handle the load, you might decide to break it into two functions — say, accounts and profiles — and put them on different databases. This would get you through the day but it’s a lot of work and it only buys you twice the capacity. Instead, you should write the code to handle the case where two users aren’t on the same database. This is probably even more work than splitting the application code in half, but it will continue to pay off for a very long time.

The most important thing here isn’t to have fancy systems for failover or load balancing. In fact, those things tend to take a lot of time and get you in trouble if you don’t get them right. You really just need to be able to split any function to run on multiple machines that operate as independently as possible.

The second lesson is to measure everything you can. Performance bottlenecks and scaling problems are often in unexpected places. The things you think will be hard are often not the biggest problems, because they’re the things you’ve thought about a lot. It’s actually a lot more like debugging than people realize. You can’t be sure your product doesn’t have bugs just by looking at the code, and similarly you can’t be sure your product will scale because you designed it well. You have to actually set it up and pound it with traffic — real or test — and measure what happens.

What is Scribe? How is it used within Facebook?

Scribe is a system we wrote to aggregate log data from thousands of servers. It turned out to be generally useful in a lot of places where you need to move large amounts of data asynchronously and you don’t need database-level reliability.

Scribe scales extremely large — I think we do more than 100 billion messages a day now. It has a simple and easy-to-use interface, and it handles temporary network or machine failures nicely.

We use Scribe for everything from logging performance data, to updating search indexes, to gathering metrics for platform apps and pages. There are more than 100 different logs in use at Facebook today.

I was struck by a phrase in one of your recent blog posts: You said Scribe has a “reasonable level of reliability for a lot of use cases.” How did you sell that internally?

For some use cases I didn’t. We can’t use the system for user data because it’s not sufficiently reliable, and keeping user data safe is something we take extremely seriously.

But there are a lot of things that aren’t user data, and in practice, data loss in Scribe is extremely rare. For many use cases it’s well worth it to be able to collect a massive amount of data.

For example, the statistics we provide to page owners depend on a large amount of data logged from the site. Some of this is from large pages where we could just take a sample of the data, but most of it is from small pages that need detailed reporting and can’t be sampled. A rare gap in this data is much better than having to limit the number of things we’re able to report to page owners, or only giving approximate numbers that aren’t useful for smaller pages.

Source How Facebook satisfied a need for speed

eclipse 3.7 has been created in the repository HEAD branch, the version code-named Indigo (indigo).

Ordinary self-hosted WordPress users know only too well that even though choosing and using thousands of available themes is a snap, creating one is an almost impossible task. You could use one of the customizable themes to modify the look to your liking, but that’s as far as you can go. Theme creating is not for the faint-hearted who are afraid to plunge into HTML, PHP and CSS coding.

But that’s not the case anymore. I recently stumbled across a WordPress theme editor plugin called Stiqr – still in beta as every other Web 2.0 service is – which can help ordinary web users to become a “skillful” web designer. If you can drag and drop objects, you can modify the look of your web. Self-hosted WordPress is officially included in the list of supported type of websites.

Read How To Modify Your WordPress Theme Via Browser Using Stiqr