Games of Gangs

Filed under: — Aviran Mordo

Working in a product company you are always in conflict between the product short term, long term goals and tasks that engineering want and need to do, but have nothing to do with the product itself, for instance improving the testing framework, building plugins for the IDE that will improve their day to day or even creating back-office tools that will solve other people in the company day to day problems or issues.
There are also tasks that engineers want to do to pay technical debt on the product, thus improving the long-term maintainability of the code.
Getting this quality time for tasks not directly related to the product development is hard as there is always pressure to release the next feature.

This is where the Guild steps in and help making it possible and creating a balance between working on features and taking care of other engineering and company wide concerns.

Like I described in the previous post, 20% of the time (one day a week) is dedicated for Guild activities. As part of the Guild activities we wanted this day to not only be about talking and learning, but also about doing. So we have created a game called “Games of Gangs).

“Games of Gangs” is a gamification of the guild tasks, which in its core is our main value of building an engineering culture and knowledge sharing.
While the first half of the day is mostly dedicated to retrospective and training, the second half of the day is dedicated to doing Guild related tasks.

A Games of Gangs task can be anything that is not directly related to the product that the engineer is working on. Also we want to enhance our engineering culture and knowledge sharing by using these tasks as a tool for learning and improving. So here are the guidelines we put for the game’s tasks (these are guidelines and not rules):
Tasks should be done in pair programing with an engineer from and different team.
Tasks should conform to at least one criterion:

  • Enhance quality
  • Improve velocity
  • Enhance our framework
  • Help another company with their own tasks
  • Share knowledge

Examples for good tasks we had are: Creating maven Archetype for new projects; reduce build time; creating CMS for our studio to manage templates; enhancing our monitoring capabilities.

To kick start this activity and to encourage people’s participation we had points assigned to tasks based on the task value and its knowledge sharing value. For instance if you do a solo task you will get only 1 point, but if you do it in pair each one will get 2 points. If you pair up with someone not from your company you will get 3 points and of you do it with someone from an off-shore office you’ll get 4 points.
You would also get points for doing lectures, writing blog posts on our engineering blog and other knowledge sharing activities.

Games of Gangs can sometimes be dedicated to a specific topic we want to push. For instance cleaning warnings in the code, or upgrading to a new Scala version.

So “Games of Gangs” has become a great way to balance between the engineering needs and the product needs while putting our engineering culture to play. It also creates the much-needed personal relationship between Guild members who do not meet on any other day as they are working for different companies at different physical locations.


MySQL Is a Great NoSQL

Filed under: — Aviran Mordo

NoSQL is a set of database technologies built to handle massive amounts of data or specific data structures foreign to relational databases. However, the choice to use a NoSQL database is often based on hype, or a wrong assumption that relational databases cannot perform as well as a NoSQL database. Operational cost is often overlooked by engineers when it comes to selecting a database. At Wix engineering, we’ve found that in most cases we don’t need a NoSQL database, and that MySQL is a great NoSQL database if it’s used appropriately.

When building a scalable system, we found that an important factor is using proven technology so that we know how to recover fast if there’s a failure. For example, you can use the latest and greatest NoSQL database, which works well in theory, but when you have production problems, how long does it take to resume normal activity? Pre-existing knowledge and experience with the system and its workings—as well as being able to Google for answers—is critical for swift mitigation. Relational databases have been around for over 40 years, and there is a vast industry knowledge of how to use and maintain them. This is one reason we usually default to using a MySQL database instead of a NoSQL database, unless NoSQL is a significantly better solution to the problem—for example, if we need a document store, or to handle high data volume that MySQL cannot handle.

However, using MySQL in a large-scale system may have performance challenges. To get great performance from MySQL, we employ a few usage patterns. One of these is avoiding database-level transactions. Transactions require that the database maintains locks, which has an adverse effect on performance.

Instead, we use logical application-level transactions, thus reducing the load and extracting high performance from the database. For example, let’s think about an invoicing schema. If there’s an invoice with multiple line items, instead of writing all the line items in a single transaction, we simply write line by line without any transaction. Once all the lines are written to the database, we write a header record, which has pointers to the line items’ IDs. This way, if something fails while writing the individual lines to the database, and the header record was not written, then the whole transaction fails. A possible downside is that there may be orphan rows in the database. We don’t see it as a significant issue though, as storage is cheap and these rows can be purged later if more space is needed.

Here are some of our other usage patterns to get great performance from MySQL:
Do not have queries with joins; only query by primary key or index.
Do not use sequential primary keys (auto-increment) because they introduce locks. Instead, use client-generated keys, such as GUIDs. Also, when you have master-master replication, auto-increment causes conflicts, so you will have to create key ranges for each instance.
Any field that is not indexed has no right to exist. Instead, we fold such fields into a single text field (JSON is a good choice).

We often use MySQL simply as a key-value store. We store a JSON object in one of the columns, which allows us to extend the schema without making database schema changes. Accessing MySQL by primary key is extremely fast, and we get submillisecond read time by primary key, which is excellent for most use cases. So we found that MySQL is a great NoSQL that’s ACID compliant.

In terms of database size, we found that a single MySQL instance can work perfectly well with hundreds of millions of records. Most of our use cases do not have more than several hundred million records in a single instance.

One big advantage to using relational databases as opposed to NoSQL is that you don’t need to deal with the eventually consistent nature displayed by most NoSQL databases. Our developers all know relational databases very well, and it makes their lives easy.

Don’t get me wrong, there is a place for NoSQL; relational databases have their limits—single host size and strict data structures. Operational cost is often overlooked by engineers in favor of the cool new thing. If the two options are viable, we believe we need to really consider what it takes to maintain it in production and decide accordingly.

This article is published on JAX Magazine.

I will be speaking at JAX London and would be happy if you join my sessions. Get 10% off if you use promo code: SPKR_JLAM
Aviran Mordo - JAX London


Building a Guild

Filed under: — Aviran Mordo

A lot of people heard about Spotify company structure of Guilds and tribes. We at Wix.com have a similar structure that has evolved over time and influenced by their ideas, however we have our own interpretation of the structure and the role of the Guild.

In this article I will try to walk down memory lane and describe my experience in building the first Guild (back-end JVM Guild) in Wix, which is now the role model of all the other Guilds at the company, and how it has evolved from the time I joined Wix when we had one back-end team of 4 developers to a about 100 back-end engineers in the back-end guild.

The Guild model did not start right away, when you are a relatively small startup all you have is teams, and this is exactly what we had. We had one server team (4 engineers) that was basically responsible for all the back-end development at Wix. As there was a demand for more back-end engineers the team grew very slowly. As with a small startup the recruitment process was very picky and we were only looking for the best engineers. At the course of a year I have only recruited 4 senior engineers. While this is very slow at this stage of the company it was very important to pick only the best engineers you can find, as these are the core engineering team that will help to build and shape the Guild and the engineering culture at the company in the future.

At this point where we had around 10 engineers we were pretty much functional teams, where everybody knew almost everything and I could move people from project to project according to the company’s priorities.

As we continue to grow (doubling the number of people every year) we saw that we are very good in focusing our efforts in some areas where are that point the company decided to invest, but were neglecting other existing products that had to compete on shared engineering resources but without any priority.

At this point we realized that we need dedicated engineers for each product group (at least for the big ones). We still didn’t have a name for that but I had essentially assigned some developers to be dedicated on some products while the other still remained shared resources.

As Wix continued its growth we had different groups of people who worked on different projects and were less engage with each other. So what we started to do is to formalize our engineering culture. While we always had a strong ownership and DevOps culture we started more and more being involved in knowledge sharing activities in order to keep our engineering teams on the cutting edge and learn from each team’s experience.

At this point we started to have discussions about how to structure the company. We looked around and found the Spotify paper. We realized that while we don’t have a name for our current structure it resembled to what Spotify had. So we adopted some of the naming and agreed that we should be working at a form of Guilds that are defined by a profession; and Gangs, which are the product teams.
Initially we only had the engineering Gangs who were dedicated to a product with all the other as shared resources across products.

This was the point where the role of the Guild had started to form.

The Guild is the one who is responsible for the person’s profession thus the Guild has the following responsibilities:

Recruitment (Hiring and firing)
Assignment to product teams according to the company’s priorities.
Setting the professional guidelines.
Set the engineers compensation (salary, bonuses etc’).
Create an engineering brand for the company.
Be responsible for the professional development / career of the engineers.

As Wix continued to grow we started to have more and more projects and product teams. What we realized then is that while having dedicated engineering teams (Gangs) is not enough because there was a bottleneck on the other shared resources. Also we had multiple products that had a common domain. What we wanted to do is to give as much independence to each product domain / vertical.

So once more we had to evolve and created what we call now a “Company”. A company is like a startup within Wix, it has all the resources it needs (developers, product manages, analysts, UX engineers, marketing etc’) in order to progress fast and create the best product they can do regardless if, the other products at Wix.

At this point the Guild also had to take on more responsibilities. While we want the “Companies” to progress as fast as they can, the “Companies” also has to keep alignment with Wix as a whole. Another issue is that we expect these “Companies” to create products that compete in the free market with other startups and big companies, but with limited resources.

The Guild now needs to play a big role in enabling the success of the “Companies” within Wix. If each “Company” had to develop everything on their own, for instance the frameworks, deployment, taking care of the infrastructure, monitoring etc’ they would not stand a chance to compete with whole companies that are doing the same product with more resources. So the Guild now took another responsibility in taking care of all the infrastructure, deployment pipeline, and core services that all the “Companies” share. For instance is we see a service that is needed in more than two companies (for example mailing service), we develop it in the Guild (which has its own core services teams) and all the other “Companies” can use this service, thus focusing only on the product itself and not having to worry about the infrastructure.

In order to keep alignment with the other “Companies”, and make it easier for engineers to move between “Companies”, share knowledge and best practices, all the “Companies” share the same infrastructure and methodologies. This is a tradeoff between freedom and velocity. You loose some freedoms but gain a lot of velocity as many of the things you need for your service are already there for you.

Now a “Company” may decide (in coordination with the Guilds) that using the existing infrastructure is the wrong solution for the product they own, and they want to develop on a different stack. They can do that, however they will need to take full responsibility over the whole application lifecycle, deployment, monitoring and integration with the other Wix echo-system. This is a lot of work and usually time to market will be very long, having to develop all the infrastructure on their own, so almost every “Company” opt-in to use the current infrastructure, although we have several cases where it was the right decision to develop some products on a different stack .

So if I was to describe the line of responsibility between a “Company” and a Guild is that the “Company” decides what to do, and the Guild say how to do it.

So now that we have “Companies” and Guilds, the Guild needs to assume more responsibilities in addition to the above:

Align between “Companies”. The Guilds are horizontal while “Companies” are verticals.
Support the engineers working in the “Companies”
Review and guidance
Develop shared infrastructure
Improving development velocity
Temporary help “Companies” in need with additional resources from the Guild.

Guild masters:
Guild masters are senior engineers that part of their responsibilities is to support engineers in different “Companies”. Guild masters conduct reviews, training, mentoring and also since they are horizontal and working with many companies they identify common issues, duplication of code between companies, understand the development bottlenecks and are trying to solve them. Also because of that they also pollinate “Companies” by bringing best practices and lessons learned from other “Companies”

Guild activities:
In order for the Guild to be able to take on these responsibilities it needs developer’s time so at Wix 20% of the engineering time is dedicated to the Guild activities.

Every Thursday we have a Guild day in which the Guild is conducting training activities and Guild tasks. All the engineers from all the “Companies” are assembled at one place for the Guild day.

Here is the back-end guild day schedule:
10:00-11:00 – Guild retrospective in which we discuss engineering dilemmas and lesson learned from across “Companies”.
11:00-11:15 – Break
11:15-11:30 – Project spotlight – where someone is presenting a new project that is being worked on, some lesson learned and challenges they have faced
11:30-13:00 (usually not the whole 1.5 hours is needed) – Tech talk, which if it does not contain any sensitive information is also open to the public at a meetup.
13:00–EOD – Lunch and Guild tasks. (The guild tasks are called “Games of Gangs”, but on “Games of Gangs” we’ll discuss on another post).


When Bad Product Makes Good Business

Filed under: — Aviran Mordo

Being the head of a large engineering group I get to interview a lot of people. As part of the interview I ask people about their current or previous jobs and some of the stories I hear horror stories about these work places and how making a bad product is actually good business for them. Here are some examples:

Example 1 – Insurance Company:
A guy that worked in an insurance company was building a system to process claim forms for elderly people. The system would validate that all the forms were submitted and that they are all filled correctly. When the developer found a validation error, for instance a missing form, missing field or a validation error he would print that there is a missing form and what exactly is missing. He was told by the company not to specify what exactly is missing but just to say some forms are missing.
By being as vague the insurance company makes the life of the elderly people who are trying to submit claims very difficult, thus having to pay less claims.

Example 2 – Outsource:
Developers that worked at an outsource company was assigned to a project. In this project he was trying to develop his code using Test Driven Development. He was told by the company not to write automated tests because the quality of code would be better and since they get paid by the hour they will loose money on debugging and manual QA, which takes much longer.

Example 3 – Banks
Some banks make the system to delay deposits and prioritize withdrawals so if a customer does not have sufficient credit they will first go into overdraft because the withdrawals are entered into the system before the deposits.
This way bank customers need to pay more interests and commissions to the bank.

Making bad products or making low quality software on purpose is a good business for some companies. However they make their customers frustrated and their employees that develop these systems unhappy and feel bad about themselves.

You would not find me working for these kinds of companies nor many good developers who have many options to find a good place to work. This actually hurt these companies in a way that they have many low quality people working for them. Good developers want to work at a place that makes them happy and they feel good about the product they develop.

What do you think, would you work for such a company?
Do you have other examples for bad companies that are benefiting from bad products?


Dev Centric Culture - Breaking Down The Walls

Filed under: — Aviran Mordo

We have been doing Continuous Delivery and DevOps at Wix for several years now and as part of that, I have been training my team at the methodology of DevOps and changing the company’s culture. Last week I was trying to explain to some colleagues how we work at Wix and about our dev culture. While doing it I realized that we are doing much more than just DevOps. What we actually do is something I call “developer centric culture” or in short “Dev Centric” culture.

What is Dev Centric culture?

Dev Centric culture is about putting the developer in the center and create a support circle around him to enable the developer to create the product you need and operate it successfully.

Dev Centric Circle

Before I’ll go into details about Dev Centric culture and why is it good let’s look on the problems we have, what we are trying to solve and why it is more than just DevOps.

DevOps is about breaking the walls between developers and operations but after few years of doing DevOps and continuous delivery we realized that DevOps is not enough. The wall between the developers and the operation is just one wall out of many. If you really want to be agile (and we do) we need to break down ALL the walls.

Let’s take a look at a traditional development pipeline.

  • Product that “tells” engineering what they need to do.
  • Software architect designs the system and “tells” the developer how to build it.
  • Developers write the code (and tests in case the work in TDD)
  • QA checks the developer’s product and cover it with more test
  • Operations deploy the artifact to production

So what we have here is a series of walls. A wall between the product and engineering, a wall between engineering and QA and of course a wall between engineering and operation. (Sometimes there is even a wall between architecture team and developers)


Continuous Delivery - Part 3 - Feature Toggles

Filed under: — Aviran Mordo

Previous chapter:The Road To Continuous Delivery - Part 2 - Visibility

UPDATE: We released PETRI our 3′rd generation experiment system as an open source project available on Github

One of the key elements in Continuous Delivery is the fact that you stop working with feature branches in your VCS repository; everybody works on the MASTER branch. During our transition to Continuous Deployment we switched from SVN to Git, which handles code merges much better, and has some other advantages over SVN; however SVN and basically every other VCS will work just fine.

For people who are just getting to know this methodology it sounds a bit crazy because they think developers cannot check-in their code until it’s completed and all the tests pass. But this is definitely not the case. Working in Continuous Deployment we tell developers to check-in their code as often as possible, at least once a day. So how can this work? Developers cannot finish their task in one day? Well there are few strategies to support this mode of development.

Feature toggles
Telling your developers they must check-in their code at least once a day will get you the reaction of something like “But my code is not finished yet, I cannot check it in”. The way to overcome this “problem” is with feature toggles.

Feature Toggle is a technique in software development that attempts to provide an alternative to maintaining multiple source code branches, called feature branches.
Continuous release and continuous deployment enables you to have quick feedback about your coding. This requires you to integrate your changes as early as possible. Feature branches introduce a by-pass to this process. Feature toggles brings you back to the track, but the execution paths of your feature is still “dead” and “untested”, if a toggle is “off”. But the effort is low to enable the new execution paths just by setting a toggle to “on”.

So what is really a feature toggle?
Feature toggle is basically an “if” statement in your code that is part of your standard code flow. If the toggle is “on” (the “if” statement == true) then the code is executed, and if the toggle is off then the code is not executed.
Every new feature you add to your system has to be wrapped in a feature toggle. This way developers can check-in unfinished code, as long as it compiles, that will never get executed until you change the toggle to “on”. If you design your code correctly you will see that in most cases you will only have ONE spot in your code for a specific feature toggle “if” statement.


The Road To Continuous Delivery - Part 2 - Visibility

Filed under: — Aviran Mordo

Previous chapter: The road to continuous delivery - Part 1

Production visibility

A key point for a successful continuous delivery is to make the production matrix available to the developers. At the heart of continuous delivery methodology is to empower the developer and make the developers responsible for deployment and successful operations of the production environment. In order for the developers to do that you should make all the information about the applications running in production easily available.

Although we give our developers root (sudo) access for the production servers, we do not want our developers to look at the logs in order to understand how the application behaves in production and to solve problems when they occur. Instead we developed a framework that every application at Wix is built on, which takes care of this concern.

Every application built with our framework automatically exposes a web dashboard that shows the application state and statistics. The dashboard shows the following (partial list):
• Server configuration
• All the RPC endpoints
• Resource Pools statistics
• Self test status (will be explained in future post)
• The list of artifacts (dependencies) and their version deployed with this version
• Feature toggles and their values
• Recent log entries (can be filtered by severity)
• A/B tests
• And most importantly we collect statistics about methods (timings, exceptions, number of calls and historical graphs).

Wix Dashboard

We use code instrumentation to automatically expose statistics on every controller and service end-point. Also developers can annotate methods they feel is important to monitor. For every method we can see the historical performance data, exception counters and also the last 10 exceptions for each method.

We have 2 categories for exceptions: Business exceptions and System exceptions.
Business exception is everything that has to do with application business logic. You will always have these kinds of exceptions like validation exceptions. The important thing to monitor on this kind of exception is to watch for sudden increase of these exceptions, especially after deployment.

The other type of exception is System exception. System exception is something like: “Cannot get JDBC connection”, or “HTTP connection timeout”. A perfect system should have zero System exceptions.


תחנות המוניות מפקיעות מחירים בניגוד לחוק

Filed under: — Aviran Mordo
לאחרונה התחלתי לנסוע מספר פעמים בחודש להרצליה במוניות. בתור אחד שרגיל לנסוע ברכב פרטי לא ממש הכרתי את המחירים. מכיוון שאני גר בפתח תקווה התקשרתי לתחנת המוניות הקרובה לביתי וביקשתי מונית להרצליה פיתוח. בתחנת המוניות אמרו לי שהנסיעה תעלה 90 שקלים. שמח וטוב לב עליתי על המונית ונסעתי להרצליה.



New Video Search Engine For Video Sharing Sites

Filed under: — Aviran Mordo

Have you ever looked for a video clip but didn’t know if the clip is on YouTube, MetaCafe, Google video or other video sharing site?

VidLookup.com comes to solve exactly this problem. VidLookup.com is a customized Google search engine that searches for video clips on many video sharing sites, thus help you find quickly the video you are looking for without you having to go and search on each site.

Right now the site searches about 30 video sharing web sites from around the web, so if you can’t find your favorite site you can suggest that site to be included in the search engine.

So next time that you want to find which site has the latest Paris Hilton clip just use VidLookup and it will search all of them.


Tip: Reduce Firefox Memory Usage

Filed under: — Aviran Mordo

Many Firefox users notice that the open source browser can take a lot of memory, sometimes several hundreds of mega bytes. Fortunately Firefox lets you control to some extent how much memory it will consume.

To set the configurations you’ll need to edit Firefox settings. To do that you’ll need to type about:config in the address bar and edit the keys we’ll discuss in this article.

Cached Pages
When a page is loaded, it can be cached so it doesn’t need to be rerendered to be redisplayed. As a default Firefox will set the amount of cache memory according to the total amount of RAM your system got. The problem with that is that these values are per tab, so the more tabs you’ve got opened the more memory Firefox cache takes.

The config parameter is browser.cache.memory.capacity and you can set it to the number of KB you want let Firefox use for cache. Value of 0 will tell Firefox not to use any memory for cache. Note that the parameter browser.cache.memory.enable has to be true

The default value is -1 where Firefox will set the memory usage according to the following values

Physical RAM Memory Cache (in KB)
32 MB 2048
64 MB 4096
128 MB 8192
256 MB 14336
512 MB 22528
1 GB 32768
2 GB 45056

4 GB 59392

In Firefox 2 these defaults will change to the following:

Physical RAM Memory Cache (in KB)
32 MB 2048
64 MB 4096
128 MB 6144
256 MB 10240
512 MB 14336
1 GB 18432

2 GB 24576
4 GB 30720

To view current memory cache usage, type about:cache?device=memory in the address bar

Pages Stored In Memory

Pages that are visited are stored in memory in such a way that they don’t have to be re-parsed. Although it sounds like cache this is different from the cache. This setting improves performance of Firefox when pressing Back and Forward buttons.

The setting key to control this behavior is: browser.sessionhistory.max_total_viewers. The default value is -1 where Firefox use the following settings based on the amount of memory your system has.

RAM Pages
32MB 0
64MB 1
128MB 2
256MB 3
512MB 5
1GB 8
2GB 8

4GB 8

This preference limits the maximum number of pages stored in memory. Setting the value to 0 do not store any pages in memory.

Let Windows claim back memory
On Windows operating systems, when a program is minimized and left for a period of time, Windows will reclaim the memory the program used in anticipation that other programs might need it. Because of the way Mozilla applications are stored in memory, Windows is much more aggressive in reclaiming the memory they use, which can cause a delay when the program is restored. This preference determines whether to allow Windows to reclaim memory from a minimized Mozilla application.

Firefox’s default setting prevents Windows from reclaiming memory when the program is minimized.

To change this settings you’ll need to change or create the key config.trim_on_minimize and set it to true or false. True - allows Windows to reclaim back the memory and false (default) prevents Windows from doing that.

Note: Changing Firefox’s settings may not be enough to stop it from taking too much memory, plugins can also be a big factor in memory consumption.


Vista’s Backup Is A Ghost Buster

Filed under: — Aviran Mordo

With the soon to be released Windows Vista, the new operating system overhauled a very important and usually overlooked feature, the backup.

Windows Vista provides a backup experience that is more comprehensive and even easier to use than the basic backup utility included in Windows XP. The new backup utility works in the background so you can use a simple wizard to schedule when and where you want it backed up. You can back up to CD-ROM, DVD-ROM, an external hard disk, another hard disk on your PC, or to another PC or server connected to your network.

Like commercial backup software such as Symantec Ghost, Vista backup can take a complete image of your hard drive, track changes and continue to backup only those changes, and of course backup individual files, specific file types and folders.

Just like Ghost, Vista backup lets you restore a complete hard drive from an image, which is most useful for corporations, that create a drive image which is then gets duplicated on many computers.

Maybe the most significant new feature Microsot introduced with Vista backup is the Previous Versions feature.
Have you ever accidentally saved over a file you were working on? Accidental file deletion or modification is a common cause of data loss. This feature automatically creates point-in-time copies of files as you work, so you can quickly and easily retrieve versions of a document you may have accidentally deleted, even after you emptied your recycle bin.

Vista Backup Previous Versions


What Vista Brings To The Table

Filed under: — Aviran Mordo

As Windows Vista release is getting closer, Microsoft releases more details on the ways Vista will work, here are some details on the fetures Vista brings to consumers.

For home users

Digital Photos - With Windows Vista operating system, consumers will have a simpler yet richer digital memories experience, with greater ability to enjoy, find, and share personal photos and video.

  • Built-in support for the most common photo-editing tasks helps consumers produce great looking prints and videos.
  • Easier backup tools and next-generation storage products will help them keep their memories safe.
  • With Windows Vista Home Premium, consumers can view and show photos on their TVs and around their homes when their PCs are connected to the TV through a wireless router or Media Center Extender.

With the Windows Vista operating system, consumers can use their PCs to make the most of their digital music collections.

  • With Windows Media Player 11, it’s easier to find and organize music content on a PC, a portable device, or even from an online service, with rich, contextual browsing and instant search.
  • Windows Vista offers better playback with improved codecs for clearer sound quality.
  • Users can utilize Windows Media Player or the Windows Vista Sync Center to synchronize their music with their portable music devices or portable media centers for maximum enjoyment on the go.
  • Safeguarding content with Windows Backup is simple and automatic, with easier CD and DVD archival, and support for archiving to PCs and networked devices.

TV & Movies
With Windows Vista Home Premium and Windows Vista Ultimate, users will find it’s easier than ever before to find, watch, record, and save all of their favorite TV shows and movies on their PCs. Users can engage and view their content throughout their homes from Windows Vista Home Premium, on their TVs, through other Windows Media Center Extender devices, or on the go with a mobile PC.

  • Users can watch live TV content or video-on-demand content through the Windows Media Center Online Spotlight.
  • Users can view their favorite content on Windows Vista Home Premium, on a mobile device with synced content, or streamed through a Windows Media Center Extender device to their TVs or another PC anywhere in their homes.
  • Users can easily back up content on recordable DVDs or on mass storage devices, protecting precious home movies, beloved TV shows, or whatever content they wish to keep safe.

New features in the Windows Vista operating system, when coupled with partner offerings, will enrich the overall gaming experience.

  • Locate all their games in one easy location.
  • Link to game sites as well as other gamers.
  • Exercise control over which games their children choose to play.

With new and improved communications tools and platforms, the Windows Vista operating system lets consumers enjoy services to share with each other more easily and securely, whether at home or on the go.

  • Windows Internet Explorer 7 lets users keep tabs on information from a variety of sources, with improved browsing, searching from multiple Internet search providers, and really simple syndication (RSS) subscriptions to their favorite Web sites.
  • Windows Vista enables centralized syncing and storage across a wider range of devices and external hard drives, while simplifying the process of setting up a home network over a wireless router with Easy Networking.
  • With Windows Defender and Windows Internet Explorer 7, users can confidently browse the Web while enjoying the multiple levels of security enhancements within Windows Vista, including spyware and malware protection; identity, data, and computer protection; and anti-phishing support.

The Windows Vista operating system offers additional ways for users to be more productive, providing them with simple tools to organize their information and perform common tasks.

  • Users are able to conduct quick, extensive, contextual searches right from the Start Menu with Instant Search.
  • Contacts make it easier for consumers to manage their personal connections, tasks, and appointments.
  • Windows Vista features improved Web browsing and easily integrates with any online search provider, putting all the information users want at their fingertips.
  • Windows Vista provides family safety settings that protect children from inappropriate Web sites and games and help prevent security breaches that result from computer misuse.

Powered by WordPress