How-To Tutorials

(For more resources related to this topic, see here.) You will observe multiple TCP connections and UDP pipes being created from both the GNS3 management console and your operating system's command line. To get a closer look at how the conductor works, open GNS3 to a new blank canvas and issue the command debug 3 in the GNS3 command console : => debug 3 As you open GNS3, the conductor readies the players awaiting your instructions. The moment you drag your first Cisco router onto the workspace, GNS3 spawns an instance of Dynamips and connects to it on port 7200. You can see this in two places: To reproduce the effects shown here, use a C7200 router image with 256MB RAM. By issuing a netstat–a command in a Windows/Linux/OS X command window: C: >netstat -an ... Proto Local Address Foreign Address State TCP 127.0.0.1:7200 0.0.0.0:0 LISTENING TCP 127.0.0.1:7200 127.0.0.1:49194 ESTABLISHED TCP 127.0.0.1:49194 127.0.0.1:7200 ESTABLISHED In the output of the GNS3 management console. The following output lines are abbreviated to conserve space: Hypervisor manager: connecting on 127.0.0.1:7200 Hypervisor manager: connected to hypervisor on 127.0.0.1 port 7200 Also in the output of the GNS3 management console , note the following (trimmed) lines: Hypervisor manager: hypervisor base UDP is 10001 …<snip>… PORT TRACKER: allocate port 2101 sending to dynamips at 127.0.0.1:7200 -> vm set_con_tcp_port R1 2101 returned -> ['100-OK'] PORT TRACKER: allocate port 2501 sending to dynamips at 127.0.0.1:7200 -> vm set_aux_tcp_port R1 2501 returned -> ['100-OK'] The UDPbase port I'll deal with shortly, but notice that GNS3 has told Dynamips to prepare to open ports 2101 and 2501 for console and AUX port communications respectively, which are the base ports defined in GNS3 Preferences for the Dynamips setting under the Dynamips tab. Also note that these ports are not yet opened, in the orchestral analogy you could say they are merely being tuned up at this stage. Next, add a second router and observe (in the console output) that the console and AUX port allocations have incremented by one, but there is no change to the base UDP port. sending to dynamips at 127.0.0.1:7200 -> vm set_con_tcp_port R2 2102 sending to dynamips at 127.0.0.1:7200 -> vm set_aux_tcp_port R2 2502 You are about to connect these two devices. Configure them with FastEthernet interfaces if necessary, or use the FastEthernet Add a link tool, and connect the two routers. Watch the console output for these lines: Connect link from R1 f1/0 to R2 f1/0 new base UDP port for dynamips at 127.0.0.1:7200 is now: 10002 new base UDP port for dynamips at 127.0.0.1:7200 is now: 10003 sending to dynamips at 127.0.0.1:7200 -> nio create_udp nio_udp0 10001 127.0.0.1 10002 sending to dynamips at 127.0.0.1:7200 -> nio create_udp nio_udp1 10002 127.0.0.1 10001 sending to dynamips at 127.0.0.1:7200 -> vm slot_add_nio_binding R1 1 0 nio_udp0 sending to dynamips at 127.0.0.1:7200 -> vm slot_add_nio_binding R2 1 0 nio_udp1 And on your host computer, netstat -an reveals: C:> netstat -an | find "1000" UDP 0.0.0.0:10001 *:* UDP 0.0.0.0:10002 *:* Understanding what is going on here is the key to understanding how Dynamips achieves communication between routers. What has just happened is that a UDP tunnel has been created between these two devices. UDP tunnel concept Links between devices in GNS3 is achieved using UDP tunnels. What this means in this scenario is that whenever R1 sends a frame from interface f1/0, the entire frame, including the Source MAC address, destination MAC address and payload, gets put inside a UDP packet with a source port of 10001 and a destination IP address:destination port of 127.0.0.1:10002 which means that the frame will end up at R2's f1/0 interface because it is bound to port 10002. The return frames take the reverse path: source port 10002, destination IP:port 127.0.0.1:10001. To illustrate this, I assigned an IP addresses of 1.1.1.1 and 1.1.1.2 to interface f1/0 on R1 and R2 respectively, then captured a ping packet on the link between R1 and R2 on the host computer's loopback interface. The Wireshark capture shown in the following screenshot shows a ping packet from 1.1.1.1 on its way to 1.1.1.2, but you can see that the entire layer 2 frame (1), including the layer 2 MAC addresses of R1 and R2 is encapsulated inside a UDP packet travelling from 127.0.0.1:10001 to 127.0.0.1:10002 (2). Another thing to note is that the first UDP port used was the Base UDP port defined in GNS3 Preferences, Dynamips settings under the Dynamips tab. Now would also be a good time to issue a show run command in the GNS3 management console window, to see how GNS3 is building up your topology.net file. => show runautostart = False [127.0.0.1:7200] workingdir = C:UserschrisAppDataLocalTempGNS3_rwftbworking udp = 10001 [[7200]] image = C:UserschrisGNS3Imagesc7200-p-mz.124-10a.image ram = 256 idlepc = 0x60750000 sparsemem = True ghostios = True [[ROUTER R1]] console = 2101 aux = 2501 slot1 = PA-2FE-TX f1/0 = R2 f1/0 [[ROUTER R2]] console = 2102 aux = 2502 slot1 = PA-2FE-TX f1/0 = R1 f1/0 Note that the amount of RAM set for each of these routers is 256MiB. Also recall that in the Hypervisor Manager settings previously shown, the Memory limit per hypervisor was set to 512MiB. Now add another router, and watch the console output, and check your host computer's TCP connections again with the netstat -an command. You will see of course: Hypervisor manager: connecting on 127.0.0.1:7201 and… TCP 127.0.0.1:7201 0.0.0.0:0 LISTENING This shows that a second hypervisor instance has been created, and allocated TCP port 7201 for communication. You will also see this reflected in the configuration information if you issue another a show run command in the GNS3 management console window. ...<Output omitted>... [127.0.0.1:7201] workingdir = C:UserschrisAppDataLocalTempGNS3_rwftbworking udp = 10101 This also reveals that the base UDP port for this hypervisor is 10101, recall that the value for the UDP incrementation in the Dynamips Hypervisor Manager setting page was 100, so the base UDP port for this instance of the hypervisor is 100 greater than the general base UDP port of 10001 for Dynamips. You can probably predict what UDP port numbers will be used then if you now connect R2 to R3 with a FastEthernet link. Make the link and see if your prediction was correct: sending to dynamips at 127.0.0.1:7200 -> nio create_udp nio_udp2 10003 127.0.0.1 10101 sending to dynamips at 127.0.0.1:7201 -> nio create_udp nio_udp3 10101 127.0.0.1 10003 sending to dynamips at 127.0.0.1:7200 -> vm slot_add_nio_binding R2 1 1 nio_udp2 sending to dynamips at 127.0.0.1:7201 -> vm slot_add_nio_binding R3 1 0 nio_udp3 Did you predict that the next connection would be made from port 10003 to 10101? Well done. But what if you add a switch or a hub? Add a generic Ethernet switch to the topology, and issue a show run command in the GNS3 management console window. You will notice that there is NO reference to the switch in the output, and in fact if you saved your topology at this point and loaded it later, there would be no switch in your topology. That is because the switch doesn't get allocated to a hypervisor until it has at least one connection to another item in the topology. The question is, since our topology has two hypervisors running, which hypervisor will be allocated the switch? Connect your recently added switch to R1. Observe what happens in the GNS3 management console, and issue another show run command in the GNS3 management console window. Here is what you are looking for: Firstly, you should see the connections being created. Note that the UDP port numbers are from the range allocated to the first hypervisor that was spawned, NOT the most recent hypervisor spawned. sending to dynamips at 127.0.0.1:7200 -> nio create_udp nio_udp4 10004 127.0.0.1 10005 sending to dynamips at 127.0.0.1:7200 -> nio create_udp nio_udp5 10005 127.0.0.1 10004 Secondly, in the topology description, you can see that SW1 has been assigned to the hypervisor running on TCP port 7200 which allocated UDP ports from the 10000+ range. What actually happens is that GNS3 assigns generic devices like switches, hubs, and clouds to the hypervisor to which the device is first connected. => show run autostart = False [127.0.0.1:7200] workingdir = C:UserschrisAppDataLocalTemp udp = 10001 [[7200]] ... [[ETHSW SW1]] 1 = access 1 R1 f1/1 [[ROUTER R1]] ... And finally, if you changed your Memory usage per hypervisor setting back on page 73, don't forget to change it back. I recommend setting it to 1024MiB . By now you are probably wondering how GNS3 and Dynamips deal with the other supported emulators: Qemu and Oracle VirtualBox . Conducting Qemu and VirtualBox Recall that Dynamips is a hypervisor used to initiate the spawning of Cisco router VMs (virtual machines) instances, and configure host communication to these VMs via console AUX and virtual network interfaces. Just like Dynamips, both Qemu and Oracle VirtualBox follow a similar hypervisor model, only in this case the hypervisor is "wrapped" to give it similar functionality to Dynamips. The wrappers for the hypervisors are called qemuwrapper and vboxwrapper respectively, and these wrappers listen on ports 10525 and 11525 as shown in the configuration options in GNS3 Preferences under the Qemu and VirtualBox settings. Trivia: Port 10525 was chosen by Thomas Pani when he wrote pemuwrapper, the wrapper for the PIX 525 emulator, port 1525 was already assigned by the IANA. Pemuwrapper evolved into qemuwrapper, and when Alexey Eromenko, alias "Technologov" wrote vboxwrapper he simply added 1000 to the qemuwrapper port number. Again, just like Dynamips, you can run qemuwrapper and vboxwrapper as standalone applications, then telnet to port 127.0.0.1:10525 or 127.0.0.1:11525 to issue commands like qemu version or vbox version or the commands to spawn a virtual machine if you bothered to learn the syntax. Again, like Dynamips, qemuwrapper and vboxwrapper direct the TCP port to be used for console connections and UDP port for UDP tunnel connections, the base values for these can also be found in GNS3 Preferences under the Qemu and VirtualBox settings. But unlike Dynamips, the wrapper is NOT the hypervisor as well. The hypervisor is Qemu or VirtualBox, so these applications had to be compiled to allow communication via UDP tunnel interfaces. In the case of Qemu prior to Version 1.1, this required a specially compiled version. The GNS3 downloads page has links to the patched Version 0.11 that I used throughout this article. VirtualBox has built-in support for UDP tunnels. To see the full GNS3 orchestra playing, you can now add Qemu and VirtualBox devices to your topology and watch the GNS3 management console and check your TCP/UDP connections with the netstat -an command. As you watch the GNS3 management console you will see the hidden power of GNS3 beyond the GNS3 GUI as it conducts its orchestral sections of Dynamips, qemuwrapper, and vboxwrapper to play in harmony, and even see that they have their own sections in the GNS3 topology.net file, as can be seen by issuing a show run command in the GNS3 management console . Summary This article covers all we need to know about the GNS3 Orcehstra—the GNS3 GUI Resources for Article: Further resources on this subject: Editing attributes [Article] iPhone JavaScript: Installing Frameworks [Article] Visualizing my Social Graph with d3.js [Article]

(For more resources related to this topic, see here.) The RWD concept appeared first in 2010 in an article by Ethan Marcotte (available at http://alistapart.com/article/responsive-web-design). He presented an approach that allows us to progressively enhance page design within different viewing contexts with the help of fluid grids, flexible images, and media queries. This approach was opposed to the one that separates websites geared toward specific devices. Instead of two or more websites (desktop and mobile), we could have one that adapts to all devices. The technical foundation of RWD (as proposed in Marcotte's article) consists of three things, fluid grids, flexible images, and media queries. Illustration: Fluid (and responsive) grid adapts to device using both column width and column count Fluid grid is basically nothing more than a concept of dividing the monitor width into modular columns, often accompanied by some kind of a CSS framework (some of the best-known examples were the 960 grid system, blueprint, pure, 1140px grid, and elastic), that is, a base stylesheet that simplifies and standardizes writing website-specific CSS. What makes it fluid is the use of relative measurements like %, em, or rem. With changing the screen (or the window), the number of these columns changes (thanks to CSS statements enclosed in media queries). This allows us to adjust the design layout to device capabilities (screen width and pixel density in particular). Images in such a layout become fluid by using a simple technique of setting width, x% or max-width, 100% in CSS, which causes the image to scale proportionally. With those two methods and a little help from media queries, one can radically change the page layout and handle this enormous, up to 800 percent, difference between the thinnest and the widest screen (WQXGA's 2560px/iPhone's 320px). This is a big step forward and a good base to start creating One Web, that is, to use one URL to deliver content to all the devices. Unfortunately, that is not enough to achieve results that would provide an equally great experience and fast loading websites for everybody. The RESS idea Besides screen width, we may need to take into account other things such as bandwidth and pay-per-bandwidth plans, processor speed, available memory, level of HTML/CSS compatibility, monitoring color depth, and possible navigation methods (touch screen, buttons, and keyboard). On a practical level, it means we may have to optimize images and navigation patterns, and reduce page complexity for some devices. To make this possible, some Server Side solutions need to be engaged. We may use Server Side just for optimizing images. Server Side optimization lets us send pages with just some elements adjusted or a completely changed page; we can rethink the application structure to build a RESTful web interface and turn our Server Side application into a web service. The more we need to place responsibility for device optimization on the Server Side, the closer we get to the old way of disparate desktops and mobile web's separate mobile domains, such as iPhone, Android, or Windows applications. There are many ways to build responsive websites but there is no golden rule to tell you which way is the best. It depends on the target audience, technical contexts, money, and time. Ultimately, the way to be chosen depends on the business decisions of the website owner. When we decide to employ Server Side logic to optimize components of a web page designed in a responsive way, we are going the RESS (Responsive Web Design with Server Side components) way. RESS was proposed by Luke Wroblewski on his blog as a result of his experiences on extending RWD with Server Side components. Essentially, the idea was based on storing IDs of resources (such as images) and serving different versions of the same resource, optimized for some defined classes of devices. Device detection and assigning them to respective classes can be based on libraries such as WURFL or YABFDL. Controversies It is worth noting that both of these approaches raised many controversies. Introducing RWD has broken some long-established rules or habits such as standard screen width (the famous 960px maximum page width limit). It has put in question the long-practiced ways of dealing with mobile web (such as separate desktop and mobile websites). It is no surprise that it raises both delight and rage. One can easily find people calling this fool's gold, useless, too difficult, a fad, amazing, future proof, and so on. Each of those opinions has a reason behind it, for better or worse. A glimpse of the following opinions may help us understand some of the key benefits and issues related to RWD. "Separate mobile websites are a good thing" You may have heard this line in an article by Jason Grigsby, Css media query for mobile is fool's gold , available at http://blog.cloudfour.com/css-media-query-for-mobile-is-fools-gold/. Separate mobile websites allow reduction of bandwidth, prepare pages that are less CPU and memory intensive, and at the same time allow us to use some mobile-only features such as geolocation. Also, not all mobile browsers are wise enough to understand media queries. That is generally true and media queries are not enough in most scenarios, but with some JavaScript (Peter-Paul Koch blog available at, http://www.quirksmode.org/blog/archives/2010/08/combining_media.html#more, describes a method to exclude some page elements or change the page structure via JS paired with media queries), it is possible to overcome many of those problems. At the same time, making a separate mobile website introduces its own problems and requires significant additional investment that can easily get to tens or hundreds of times more than the RWD solution (detecting devices, changing application logic, writing separate templates, integrating, and testing the whole thing). Also, at the end of the day, your visitors may prefer the mobile version, but this doesn't have to be the case. Users are often accessing the same content via various devices and providing consistent experience across all of them becomes more and more important. The preceding controversy is just a part of a wider discussion on channels to provide content on the Internet. RWD and RESS are relatively new kids on the block. For years, technologies to provide content for mobile devices were being built and used, from device-detection libraries to platform-specific applications (such as iStore, Google Play, and MS). When, in 2010, US smartphone users started to spend more time using their mobile apps than browsers (Mobile App Usage Further Dominates Web, Spurred by Facebook, at http://blog.flurry.com/bid/80241/Mobile-App-Usage-Further-Dominates-Web-Spurred-by-Facebook), some hailed it as dangerous for the Web (Apps: The Web Is The Platform, available at http://blog.mozilla.org/webdev/2012/09/14/apps-the-web-is-the-platform/). A closer look at stats reveals though, that most of this time was spent on playing games. No matter how much time kids can spend playing Angry Birds now, after more than two years from then, people still prefer to read the news via a browser rather than via native mobile applications. The Future of Mobile News report from October 2012 reveals that for accessing news, 61 percent mobile users prefer a browser while 28 percent would rather use apps (Future of Mobile News, http://www.journalism.org/analysis_report/future_mobile_news). The British government is not keen on apps either, as they say, "Our position is that native apps are rarely justified" (UK Digital Cabinet Office blog, at http://digital.cabinetoffice.gov.uk/2013/03/12/were-not-appy-not-appy-at-all/). Recently, Tim Berners-Lee, the inventor of the Web, criticized closed world apps such as those released by Apple for threatening openness and universality that the architects of the Internet saw as central to its design. He explains it the following way, "When you make a link, you can link to anything. That means people must be able to put anything on the Web, no matter what computer they have, what software they use, or which human language they speak and regardless of whether they have a wired or a wireless Internet connection." This kind of thinking goes in line with the RWD/RESS philosophy to have one URL for the same content, no matter what way you'd like to access it. Nonetheless, it is just one of the reasons why RWD became so popular during the last year. "RWD is too difficult" CSS coupled with JS can get really complex (some would say messy) and requires a lot of testing on all target browsers/platforms. That is or was true. Building RWD websites requires good CSS knowledge and some battlefield experience in this field. But hey, learning is the most important skill in this industry. It actually gets easier and easier with new tools released nearly every week. "RWD means degrading design" Fluid layouts break the composition of the page; Mobile First and Progressive Enhancement mean, in fact, reducing design to a few simplistic and naive patterns. Actually the Mobile First concept contains two concepts. One is design direction and the second is the structure of CSS stylesheets, in particular the order of media queries. With regard to design direction, the Mobile First concept is meant to describe the sequence of designs. First the design for a mobile should be created and then for a desktop. While there are several good reasons for using this approach, one should never forget the basic truth that at the end of the day only the quality of designs matters, not the order they were created in. With regard to the stylesheet structure, Mobile First means that we first write statements for small screens and then add statements for wider screens, such as @media screen and (min-width: 480px). It is a design principle meant to simplify the whole thing. It is assumed here that CSS for small screens is the simplest version, which will be progressively enhanced for larger screens. The idea is smart and helps to maintain a well-structured CSS but sometimes the opposite, the Desktop First approach, seems natural. Typical examples are tables with many columns. The Mobile First principle is not a religious dogma and should not be treated as such. As a side note, it remains an open question why this is still named Mobile First, while the new iPad-related statements should come here at the end (min-width: 2000px). There are some examples of rather poor designs made by RWD celebrities. But there are also examples of great designs that happened, thanks to the freedom that RWD gave to the web design world. The rapid increase in Internet access via mobile devices during 2012 made RWD one of the hottest topics in web design. The numbers vary across countries and websites but no matter what numbers you look at, one thing is certain, mobile is already big and will soon get even bigger (valuable stats on mobile use are available at http://www.thinkwithgoogle.com/mobileplanet/en/). Statistics are not the only reason why Responsive Web Design became popular. Equally important are the benefits for web designers, users, website owners, and developers. Summary This article, as discussed, covered the RESS idea, as well as the controversies associated with it. Resources for Article: Further resources on this subject: Introduction to RWD frameworks [Article] Getting started with Modernizr using PHP IDE [Article] Understanding Express Routes [Article]

(For more resources related to this topic, see here.) The prerequisites for Zimbra Let us dive into the prerequisites for Zimbra: Zimbra supports only 64-bit LTS versions of Ubuntu, release 10.04 and above. If you would like to use a 32-bit version, you should use Ubuntu 8.04.x LTS with Zimbra 7.2.3. Having a clean and freshly installed system is preferred for Zimbra; it requires a dedicated system and there is no need to install components such as Apache and MySQL since the Zimbra server contains all the components it needs. Note that installing Zimbra with another service (such as a web server) on the same server can cause operational issues. The dependencies (libperl5.14, libgmp3c2, build-essential, sqlite3, sysstat, and ntp) should be installed beforehand. Configure a fixed IP address on the server. Have a domain name and a well-configured DNS (A and MX entries) that points to the server. The system clocks should be synced on all servers. Configure the file /etc/resolv.conf on all servers to point at the server on which we installed the bind (it can be installed on any Zimbra server or on a separate server). We will explain this point in detail later. Preparing the environment Before starting the Zimbra installation process, we should prepare the environment. In the first part of this section, we will see the different possible configurations and then, in the second part, we will present the needed assumptions to apply the chosen configuration. Multiserver configuration examples One of the greatest advantages of Zimbra is its scalability; we can deploy it for a small business with few mail accounts as well as for a huge organization with thousands of mail accounts. There are many possible configuration options; the following are the most used out of those: Small configuration: All Zimbra components are installed on only one server. Medium configuration: Here, LDAP and message store are installed on one server and Zimbra MTA on a separate server. Note here that we can use more Zimbra MTA servers so we can scale easier for large incoming or outgoing e-mail volume. Large configuration: In this case, LDAP will be installed on a dedicated server and we will have multiple mailbox and MTA servers, so we can scale easier for a large number of users. Very large configuration: The difference between this configuration and large one is the existence of an additional LDAP server, so we will have a Master LDAP and its replica. We choose the medium configuration; so, we will install LDAP and mailbox in one server and MTA on the other server. Install different servers in the following order (for medium configuration, 1 and 2 are combined in only one step): 1. First of all, install and configure the LDAP server. 2. Then, install and configure Zimbra mailbox servers. 3. Finally, install Zimbra MTA servers and finish the whole installation configuration. New installations of Zimbra limit spam/ham training to the first installed MTA. If you uninstall or move this MTA, you should enable spam/ham training on another MTA as one host should have this enabled to run zmtrainsa --cleanup. To do this, execute the following command: zmlocalconfig -e zmtrainsa_cleanup_host=TRUE Assumptions In this article, we will use some specific information as input in the Zimbra installation process, which, in most cases, will be different for each user. Therefore, we will note some of the most redundant ones in this section. Remember that you should specify your own values rather than using the arbitrary values that I have provided. The following is the list of assumptions used : OS version: ubuntu-12.04.2-server-amd64 Zimbra version: zcs-8.0.3_GA_5664.UBUNTU12_64.20130305090204 MTA server name: mta MTA hostname: mta.zimbra-essentials.com Internet domain: zimbra-essentials.com MTA server IP address: 172.16.126.141 MTA server IP subnet mask: 255.255.255.0 MTA server IP gateway: 172.16.126.1 Internal DNS server: 172.16.126.11 External DNS server: 8.8.8.8 MTA admin ID: abdelmonam MTA admin Password: Z!mbra@dm1n Zimbra admin Password: zimbrabook MTA server name: ldap MTA hostname: ldap.zimbra-essentials.com LDAP server IP address: 172.16.126.140 LDAP server IP subnet mask: 255.255.255.0 LDAP server IP gateway: 172.16.126.1 Internal DNS server: 172.16.126.11 External DNS server: 8.8.8.8 LDAP admin ID: abdelmonam LDAP admin password: Z!mbra@dm1n To be able to follow the steps described in the next sections, especially each time we need to perform a configuration, the reader should know how to harness the vi editor. If not, you should develop your skill set for using the vi editor or use another editor instead. You can find good basic training for the vi editor at http://www.cs.colostate.edu/helpdocs/vi.html System requirements For the various system requirements, please refer to the following link: http://www.zimbra.com/docs/os/8.0.0/multi_server_install/wwhelp/wwhimpl/common/html/wwhelp.htm#href=ZCS_Multiserver_Open_8.0.System_Requirements_for_VMware_Zimbra_Collaboration_Server_8.0.html&single=true If you are using another version of Zimbra, please check the correct requirements on the Zimbra website. Ubuntu server installation First of all, choose the appropriate language. Choose Install Ubuntu Server and then press Enter. When the installation prompts you to provide a hostname, configure only a one-word hostname; in the Assumptions section, we've chosen ldap for the LDAP and mailstore server and mta for the MTA server—don't give the fully qualified domain name (for example, mta.zimbra-essentials.com). On the next screen that calls for the domain name, assign it zimbra-essentials.com (without the hostname). The hard disk setup is simple if you are using a single drive; however, in the case of a server, it's not the best way to do things. There are a lot of options for partitioning your drives. In our case, we just make a little partition (2x RAM) for swapping, and what remains will be used for the whole system. Others can recommend separate partitions for mailstore, system, and so on. Feel free to use the recommendation you want depending on your IT architecture; use your own judgment here or ask your IT manager. After finishing the partitioning task, you will be asked to enter the username and password; you can choose what you want except admin and zimbra. When asked if you want to encrypt the home directory, select No and then press Enter. Press Enter to accept an empty entry for the HTTP proxy. Choose Install security updates automatically and then press Enter. On the Software Selection screen, you must select the DNS Server and the OpenSSH Server choices for installation; no other options. This will authorize remote administration (SSH) and mandatorily set up bind9 for a split DNS. For bind9, you can install it on only one server, which is what we've done in this article. Select Yes and then press Enter to install the GRUB boot loader to the master boot record. The installation should have completed successfully. Preparing Ubuntu for Zimbra installation In order to prepare the Ubuntu for the Zimbra installation, the following steps need to be performed: Log in to the newly installed system and update and upgrade Ubuntu using the following commands: sudo apt-get update sudo apt-get upgrade Install the dependencies as follows: sudo apt-get install libperl5.14 libgmp3c2 build-essential sqlite3 sysstat ntp Zimbra recommends (but there's no obligation) to disable and remove Apparmor. sudo /etc/init.d/apparmor stop sudo /etc/init.d/apparmor teardown sudo update-rc.d -f apparmor remove sudo aptitude remove apparmor apparmor-utils Set the static IP for your server as follows: Open the network interfaces file using the following command: sudo vi /etc/network/interfaces Then replace the following line: iface eth0 inet dhcp With: iface eth0 inet static address 172.16.126.14 netmask 255.255.255.0 gateway 172.16.126.1 network 172.16.126.0 broadcast 172.16.126.255 Restart the network process by typing in the following: sudo /etc/init.d/networking restart Sanity test! To verify that your network configuration is configured properly, type in ifconfig and ensure that the settings are correct. Then try to ping any working website (such as google.com) to see if that works. On each server, pay attention when you set the static IP address (172.16.126.140 for the LDAP server and 172.16.126.141 for the MTA server). Summary In this article, we learned the prerequisites for Zimbra multiserver installation and preparing the environment for the installation of the Zimbra server in a multiserver environment. Resources for Article : Further resources on this subject: Routing Rules in AsteriskNOW - The Calling Rules Tables [Article] Users, Profiles, and Connections in Elgg [Article] Integrating Zimbra Collaboration Suite with Microsoft Outlook [Article]

(For more resources related to this topic, see here.) When you add a new instance to your project, it is automatically started. After a few moments, it will be ready for logging in using SSH. In order to create and start an instance, run the following command: % gcutil –-project=<project_id> addinstance <instance_name> gcutil will interactively collect the necessary details on the command line. For our example, we create a new instance called hello-google-compute: % gcutil –project=packt-gce-starter addinstance hello-gce INFO: Waiting for insert of instance hello-gce. Sleeping for 3s. [omitted] The omitted output will show information on the zone, image, and machine type selected during interactive setup and provide a return code to indicate whether the operation was successful. If you wish to create an instance non-interactively, you will have to set a few additional parameters. The instance name must only contain lower-case letters, numbers, or dashes and it must start with a letter. Option Description --machine-type The machine type to host the instance. gcutillistmachinetypes displays a list of available machine types, and gcutil getmachinetype provides details on a specific machine type. --image The name of the image to install, from the project's images collection. gcutil listimages displays a list of available images, and gcutil getimage provides details on a specific image. A comprehensive list of options can be listed by running the following command: % gcutil help addinstance After creation, your instance will be also displayed in the Google Cloud Console. % gcutil --project=<project_id> listinstances By default, every instance has a network setup that allows the virtual machine to communicate with other machines in the same network and with the rest of the world via the Internet. Note that, however, communication is restricted by the default firewall to incoming SSH traffic; see The Firewall object section for details. Information on a newly created instance   Checking the status of an instance After having started an instance, or for routine checks during the management of your GCE infrastructure, you may want to check the status of a given virtual machine. This can be done either via the Web UI, as shown in the preceding screenshot, or by calling: % gcutil --project=<project_id> getinstance <instance_name> For our test instance, this will yield something like: % gcutil –-project=packt-gce-starter getinstance hello-gce +------------------------+-------------------------------------+ | property | value | +------------------------+-------------------------------------+ | name | hello-gce | | description | | | creation-time | 2013-05-27T11:02:54.825-07:00 | | machine | machineTypes/n1-standard-1 | | | | | status | RUNNING | | status-message | | | | | | disk | 0 | | type | EPHEMERAL | | mode | READ_WRITE | | | | | network-interface | | | network | networks/default | | ip | 10.240.17.7 | | access-configuration | External NAT | | type | ONE_TO_ONE_NAT | | external-ip | 192.158.30.140 | +------------------------+-------------------------------------+ Note the status line within the above output; it says RUNNING. This indicates that the machine is ready to be used. GCE instance states and transitions   Every instance in GCE has a defined status lifecycle, as shown in the preceding figure, and the following states are known: Status Description PROVISIONING Resources are being reserved for the instance, but the virtual machine is not running yet. STAGING Resources have been acquired for the instance, and the virtual machine is prepared for launch. RUNNING The instance is booting up or running. STOPPED The instance has been either shutdown, or it failed. Subsequently, it will either reboot (changing to PROVISIONING), or stop (changing to TERMINATED). TERMINATED The instance has been either shutdown or it failed, and rebooting the virtual machine is not an option. This status is permanent, and the instance must be deleted and recreated. Logging in to your instance As mentioned before, the default network setup allows you to connect to your instance via the SSH protocol. GCE automatically handles key management for you and your project members. To relieve you from the hassle of key handling, gcutil wraps SSH and takes care of sorting out password-less authentication correctly. To login to your instance via SSH, run the following command from your workstation computer: % gcutil --project=<project_id> ssh <instance_name> For our example, you would do the following: % gcutil --project=packt-gce-starter ssh hello-gce INFO: Zone for 'hello-gce' detected as u'europe-west1-a'. INFO: Running command line: ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no -i /Users/packt/.ssh/google_compute_engine -A -p 22 packt@192.158.30.140 -- [omitted] packt@hello-gce:~$ As mentioned before, GCE takes care of SSH through the gcutil. In fact, gcutil does a lot! Most importantly, it checks whether you already have a public/private key pair and, if not, creates one for you. It also takes care of uploading your public key to the Google Cloud Console and associating it with your Google user account. In addition, it automatically injects your public key into every instance so that you can directly login, even if you did not set up a user account within the OS image. If you wish to use a different SSH client, you will have to manage usage and the upload of the correct key manually. gcutil stores the generated key pair in your home folder under the hidden directory ~/.ssh. There, you will (besides others) find two files: google_compute_engine (your private key) google_compute_engine.pub (your public key) Even if you do not wish to use gcutil for SSH'ing into your virtual machines, you should go through its setup routine at least once so that your keys are generated and uploaded to the Google Cloud Console; otherwise, you will not be able to login. One ring to rule them all During initial key ring generation, gcutil will ask you to enter and repeat a passphrase to protect your SSH key. Although you can leave the passphrase empty, we strongly recommend not doing so. If you do not protect your key with a passphrase, anyone who gets hold of your workstation computer can easily copy your key and will then have full administrative access to your whole GCE infrastructure! Summary Thus we learned how to get started with creating and running your infrastructure in the Cloud and few concepts that make up a well-performing GCE system. Resources for Article : Further resources on this subject: Blogger: Improving Your Blog with Google Analytics and Search Engine Optimization [Article] Google Earth, Google Maps and Your Photos: a Tutorial [Article] Search Engine Optimization using Sitemaps in Drupal 6 [Article]

(For more resources related to this topic, see here.) Cloudera Hadoop Hadoop is one of the names we think about when it comes to Big Data. I'm not going into details about it since there is plenty of information out there; moreover, like somebody once said, "If you decided to use Hadoop for your data warehouse, then you probably have a good reason for it". Let's not forget: it is primarily a distributed filesystem, not a relational database. That said, there are many cases when we may need to use this technology for number crunching, for example, together with MicroStrategy for analysis and reporting. There are mainly two ways to leverage Hadoop data from MicroStrategy: the first is Hive and the second is Impala. They both work as SQL bridges to the underlying Hadoop structures, converting standard SELECT statements into jobs. The connection is handled by a proprietary 32-bit ODBC driver available for free from the Cloudera website. In my tests, Impala resulted largely faster than Hive, so I will show you how to use it from our MicroStrategy virtual machine. Please note that I am using Version 9.3.0 for consistency with the rest of the book. If you're serious about Big Data and Hadoop, I strongly recommend upgrading to 9.3.1 for enhanced performance and easier setup. See MicroStrategy knowledge base document TN43588 : Post-Certification of Cloudera Impala 1.0 with MicroStrategy 9.3.1 . The ODBC driver is the same for both Hive and Impala, only the driver settings change. Connecting to a Hadoop database To show how we can connect to a Hadoop database, I will use two virtual machines: one with MicroStrategy Suite and the second with Cloudera Hadoop distribution, specifically, a virtual appliance that is available for download from their website. The configuration of the Hadoop cluster is out of scope; moreover, I am not a Hadoop expert. I'll simply give some hints, feel free to use any other configuration/vendor, the procedure and ODBC parameters should be similar. Getting ready Start by going to http://at5.us/AppAU1 The Cloudera VM download is almost 3 GB (cloudera-quickstart-vm-4.3.0-vmware.tar.gz) and features the CH4 version. After unpacking the archive, you'll find a cloudera-quickstart-vm-4.3.0-vmware.ovf file that can be opened with VMware, see screen capture: Accept the defaults and click on Import to generate the cloudera-quickstart-vm-4.3.0-vmware virtual machine. Before starting the Cloudera appliance, change the network card settings from NAT to Bridged since we need to access the database from another VM: Leave the rest of the parameters, as per the default, and start the machine. After a while, you'll be presented with a graphical interface of Centos Linux. If the network has started correctly, the machine should have received an IP address from your network DHCP. We need a fixed rather than dynamic address in the Hadoop VM, so: Open the System | Preferences | Network Connections menu. Select the name of your card (should be something like Auto eth1 ) and click on Edit… . Move to the IPv4 Settings tab and change the Method from Automatic (DHCP) to Manual . Click on the Add button to create a new address. Ask your network administrator for details here and fill Address , Netmask , and Gateway . Click on Apply… and when prompted type the root password cloudera and click on Authenticate . Then click on Close . Check if the change was successful by opening a Terminal window (Applications | System Tools | Terminal ) and issue the ifconfig command, the answer should include the address that you typed in step 4. From the MicroStrategy Suite virtual machine, test if you can ping the Cloudera VM. When we first start Hadoop, there are no tables in the database, so we create the samples: In the Cloudera virtual machine, from the main page in Firefox open Cloudera Manager , click on I Agree in the Information Assurance Policy dialog. Log in with username admin and password admin. Look for a line with a service named oozie1 , notice that it is stopped. Click on the Actions button and select Start… . Confirm with the Start button in the dialog. A Status window will pop up, wait until the Progress is reported as Finished and close it. Now click on the Hue button in the bookmarks toolbar. Sign up with username admin and password admin, you are now in the Hue home page. Click on the first button in the blue Hue toolbar (tool tip: About Hue ) to go to the quick Start Wizard . Click on the Next button to go to Step 2: Examples tab. Click on Beeswax (Hive UI) and wait until a message over the toolbar says Examples refreshed . Now in the Hue toolbar, click on the seventh button from the left (tool tip: Metastore Manager ), you will see the default database with two tables: sample_07 and sample_08 . Enable the checkbox of sample_08 and click on the Browse Data button. After a while the Results tab shows a grid with data. So far so good. We now go back to the Cloudera Manager to start the Impala service. Click on the Cloudera Manager bookmark button. In the Impala1 row, open the Actions menu and choose Start… , then confirm Start . Wait until the Progress says Finished , then click on Close in the command details window. Go back to Hue and click on the fourth button on the toolbar (tool tip: Cloudera Impala (TM) Query UI ). In the Query Editor text area, type select * from sample_08 and click on Execute to see the table content. Next, we open the MicroStrategy virtual machine and download the 32-bit Cloudera ODBC Driver for Apache Hive, Version 2.0 from http://at5.us/AppAU2. Download the ClouderaHiveODBCSetup_v2_00.exe file and save it in C:install. How to do it... We install the ODBC driver: Run C:installClouderaHiveODBCSetup_v2_00.exe and click on the Next button until you reach Finish at the end of the setup, accepting every default. Go to Start | All Programs | Administrative Tools | Data Sources (ODBC) to open the 32-bit ODBC Data Source Administrator (if you're on 64-bit Windows, it's in the SysWOW64 folder). Click on System DSN and hit the Add… button. Select Cloudera ODBC Driver for Apache Hive and click on Finish . Fill the Hive ODBC DSN Configuration with these case-sensitive parameters (change the Host IP according to the address used in step 4 of the Getting ready section): Data Source Name : Cloudera VM Host : 192.168.1.40 Port : 21050 Database : default Type : HS2NoSasl Click on OK and then on OK again to close the ODBC Data Source Administrator. Now open the MicroStrategy Desktop application and log in with administrator and the corresponding password. Right-click on MicroStrategy Analytics Modules and select Create New Project… . Click on the Create project button and name it HADOOP, uncheck Enable Change Journal for this project and click on OK . When the wizard finishes creating the project click on Select tables from the Warehouse Catalog and hit the button labeled New… . Click on Next and type Cloudera VM in the Name textbox of the Database Instance Definition window. In this same window, open the Database type combobox and scroll down until you find Generic DBMS . Click on Next . In Local system ODBC data sources , pick Cloudera VM and type admin in both Database login and Password textboxes. Click on Next , then on Finish , and then on OK . When a Warehouse Catalog Browser error appears, click on Yes . In the Warehouse Catalog Options window, click on Edit… on the right below Cloudera VM . Select the Advanced tab and enable the radio button labeled Use 2.0 ODBC calls in the ODBC Version group. Click on OK . Now select the category Catalog | Read Settings in the left tree and enable the first radio button labeled Use standard ODBC calls to obtain the database catalog . Click on OK to close this window. When the Warehouse Catalog window appears, click on the lightning button (tool tip: Read the Warehouse Catalog ) to refresh the list of available tables. Pick sample_08 and move it to the right of the shopping cart. Then right-click on it and choose Import Prefix . Click on Save and Close and then on OK twice to close the Project Creation Assistant . You can now open the project and update the schema. From here, the procedure to create objects is the same as in any other project: Go to the Schema Objects | Attributes folder, and create a new Job attribute with these columns: ID : Table: sample_08 Column: code DESC : Table: sample_08 Column: description Go to the Fact folder and create a new Salary fact with salary column. Update the schema. Go to the Public Objects | Metrics folder and create a new Salary metric based on the Salary fact with Sum as aggregation function. Go to My Personal Objects | My Reports and create a new report with the Job attribute and the Salary metric: There you go; you just created your first Hadoop report. How it works... Executing Hadoop reports is no different from running any other standard DBMS reports. The ODBC driver handles the communication with Cloudera machine and Impala manages the creation of jobs to retrieve data. From MicroStrategy perspective, it is just another SELECT query that returns a dataset. There's more... Impala and Hive do not support the whole set of ANSI SQL syntax, so in some cases you may receive an error if a specific feature is not implemented: See the Cloudera documentation for details. HP Vertica Vertica Analytic Database is grid-based, column-oriented, and designed to manage large, fast-growing volumes of data while providing rapid query performance. It features a storage organization that favors SELECT statements over UPDATE and DELETE plus a high compression that stores columns of homogeneous datatype together. The Community (free) Edition allows up to three hosts and 1 TB of data, which is fairly sufficient for small to medium BI projects with MicroStrategy. There are several clients available for different operating systems, including 32-bit and 64-bit ODBC drivers for Windows.

(For more resources related to this topic, see here.) We'll first have a quick overview of the features of BeagleBoard (with focus on the latest xM version) —an open source hardware platform, borne for audio, video, and digital signal processing. Then we will introduce the concept of rapid prototyping and explain what we can do with the BeagleBoard support tools from MATLAB® and Simulink® by MathWorks®. Finally, this article ends with a summary. Different from most approaches that involve coding and compiling at a Linux PC and require intensive manual configuration in command-line manner, the rapid prototyping approach presented in this article is a Windows-based approach that features a Windows PC for embedded software development through user-friendly graphic interaction and relieves the developer from intensive coding so that you can concentrate on your application and algorithms and have the BeagleBoard run your inspiration. First of all, let's begin with a quick overview of this article. A quick overview of the BeagleBoard's functionality We can create a number of exciting projects to demonstrate how to build a prototype of an embedded audio, video, and digital signal processing system rapidly without intensive programming and coding. The main projects include: Installing Linux for BeagleBoard from a Windows PC Developing C/C++ with Eclipse on a Windows PC Automatic embedded code generation for BeagleBoard Serial communication and digital I/O application: Infrared motion detection Audio application: voice recognition Video application: motion detection These projects provide the workflow of building an embedded system. With the help of various online documents you can learn about setting up the development environment, writing software at a host PC running Microsoft Windows, and compiling the code for standalone ARM-executables at the BeagleBoard running Linux. Then you can learn the skills of rapid prototyping embedded audio and video systems via the BeagleBoard support tools from Simulink by MathWorks. The main features of these techniques include: Open source hardware A Windows-based friendly development environment Rapid prototyping and easy learning without intensive coding These features will save you from intensive coding and will also relieve the pressure on you to build an embedded audio/video processing system without learning the complicated embedded Linux. The rapid prototyping techniques presented allow you to concentrate on your brilliant concept and algorithm design, rather than being distracted by the complicated embedded system and low-level manual programming. This is beneficial for students and academics who are primarily interested in the development of audio/video processing algorithms, and want to build an embedded prototype for proof-of-concept quickly. BeagleBoard-xM BeagleBoard, the brainchild of a small group of Texas Instruments (TI) engineers and volunteers, is a pocket-sized, low-cost, fan-less, single-board computer containing TI Open Multimedia Application Platform 3 (OMAP3) System on a chip (SoC) processor, which integrates a 1 GHz ARM core and a TI's Digital Signal Processor (DSP) together. Since many consumer electronics devices nowadays run some form of embedded Linux-based environment and usually are on an ARM-based platform, the BeagleBoard was proposed as an inexpensive development kit for hobbyists, academics, and professionals for high-performance, ARM-based embedded system learning and evaluation. As an open hardware embedded computer with open source software development in mind, the BeagleBoard was created for audio, video, and digital signal processing with the purpose of meeting the demands of those who want to get involved with embedded system development and build their own embedded devices or solutions. Furthermore, by utilizing standard interfaces, the BeagleBoard comes with all of the expandability of today's desktop machines. The developers can easily bring their own peripherals and turn the pocket-sized BeagleBoard into a single-board computer with many additional features. The following figure shows the PCB layout and major components of the latest xM version of the BeagleBoard. The BeagleBoard-xM (referred to as BeagleBoard in this article unless specified otherwise) is an 8.25 x 8.25cm (3.25" x 3.25") circuit board that includes the following components: CPU: TI's DM3730 processor, which houses a 1 GHz ARM Cortex-A8 superscalar core and a TI's C64x+ DSP core. The power of the 32-bit ARM and C64+ DSP, plus a large amount of onboard DDR RAM arm the BeagleBoard with the capacity to deal with computational intensive tasks, such as audio and video processing. Memory: 512 MB MDDR SDRAM working 166MHz. The processor and the 512 MB RAM comes in a .44 mm (Package on Package) POP package, where the memory is mounted on top of the processor. microSD card slot: being provided as a means for the main nonvolatile memory. The SD cards are where we install our operating system and will act as a hard disk. The BeagleBoard is shipped with a 4GB microSD card containing factory-validated software (actually, an Angstrom distribution of embedded Linux tailored for BeagleBoard). Of course, this storage can be easily expanded by using, for example, an USB portable hard drive. USB2.0 On-The-Go (OTG) mini port: This port can be used as a communication link to a host PC and the power source deriving power from the PC over the USB cable. 4-port USB-2.0 hub: These four USB Type A connectors with full LS/FS/HS support. Each port can provide power on/off control and up to 500 mA as long as the input DC to the BeagleBoard is at least 3 A. RS232 port: A single RS232 port via UART3 of DM3730 processor is provided by a DB9 connector on BeagleBoard-xM. A USB-to-serial cable can be plugged directly into the DB9 connector. By default, when the BeagleBoard boots, system information will be sent to the RS232 port and you can log in to the BeagleBoard through it. 10/100 M Ethernet: The Ethernet port features auto-MDIX, which works for both crossover cable and straight-through cable. Stereo audio output and input: BeagleBoard has a hardware accelerated audio encoding and decoding (CODEC) chip and provides stereo in and out ports via two 3.5 mm jacks to support external audio devices, such as headphones, powered speakers, and microphones (either stereo or mono). Video interfaces: It includes S-video and Digital Visual Interface (DVI)-D output, LCD port, a Camera port. Joint Test Action Group (JTAG) connector: reset button, a user button, and many developer-friendly expansion connectors. The user button can be used as an application button. To get going, we need to power the BeagleBoard by either the USB OTG mini port, which just provides current of up to 500 mA to run the board alone, or a 5V power source to run with external peripherals. The BeagleBoard boots from the microSD card once the power is on. Various alternative software images are available on the BeagleBoard website, so we can replace the factory default images and have the BeagleBoard run with many other popular embedded operating systems (like Andria and Windows CE). The off-the-shelf expansion via standard interfaces on the BeagleBoard allows developers to choose various components and operating systems they prefer to build their own embedded solutions or a desktop-like system as shown below: BeagleBoard for rapid prototyping A rapid prototyping approach allows you to quickly create a working implementation of your proof-of-concept and verify your audio or video applications on hardware early, which overcomes barriers in the design-implementation-validation loops and helps you find the right solution for your applications. Rapid prototyping not only reduces the development time from concept to product, but also allows you to identify defects and mistakes in system and algorithm design at an early stage. Prototyping your concept and evaluating its performance on a target hardware platform gives you confidence in your design, and promotes its success in applications. The powerful BeagleBoard equipped with many standard interfaces provides a good hardware platform for rapid embedded system prototyping. On the other hand, the rapid prototyping tool, the BeagleBoard Support from Simulink package, provided by MathWorks with graphic user interface (GUI) allows developers to easily implement their concept and algorithm graphically in Simulink, and then directly run the algorithms at the BeagleBoard. In short, you design algorithms in MATLAB/Simulink and see them perform as a standalone application on the BeagleBoard. In this way, you can concentrate on your brilliant concept and algorithm design, rather than being distracted by the complicated embedded system and low-level manual programming. The prototyping tool reduces the steep learning curve of embedded systems and helps hobbyists, students, and academics who have a great idea, but have little background knowledge of embedded systems. This feature is particularly useful to those who want to build a prototype of their applications in a short time. MathWorks introduced the BeagleBoard support package for rapid prototyping in 2010. Since the release of MATLAB 2012a, support for the BeagleBoard-xM has been integrated into Simulink and is also available in the student version of MATLAB and Simulink. Your rapid prototyping starts with modeling your systems and implementing algorithms in MATLAB and Simulink. From your models, you can automatically generate algorithmic C code along with processor-specific, real-time scheduling code and peripheral drivers, and run them as standalone executables on embedded processors in real time. The following steps provide an overview of the work flow for BeagleBoard rapid prototyping in MATLAB/Simulink: Create algorithms for various applications in Simulink and MATLAB with a user-friendly GUI. The applications can be audio processing (for example, digital amplifiers), computer vision applications (for example, object tracking), control systems (for example, flight control), and so on. Verify and improve the algorithm work by simulation. With intensive simulation, it is expected that most defects, errors, and mistakes in algorithms will be identified. Then the algorithms are easily modified and updated to fix the identified issues. Run the algorithms as standalone applications on the BeagleBoard. Interactive parameter turning, signal monitoring, and performance optimization of applications running on the BeagleBoard. Summary In this article, we have familiarized ourselves with the BeagleBoard and rapid prototyping by using MATLAB/Simulink. We have also looked at some of the features of rapid prototyping and the basic steps in rapid prototyping in MATLAB/Simulink. Resources for Article: Further resources on this subject: 2-Dimensional Image Filtering [Article] Creating Interactive Graphics and Animation [Article] Advanced Matplotlib: Part 1 [Article]

(For more resources related to this topic, see here.) The Hello World application In the previous sections, we saw how to set up environments for development of Sencha Touch. Now let's start with the Hello World application. First of all, create a new folder in your web server and name it sencha-touch-start. Create a subfolder lib inside this folder. In this folder, we will store our Sencha Touch resources. Create two more subfolders inside the lib folder and name them js and css respectively. Copy the sencha-touch-all.js file from the SDK, which we had downloaded, to the lib/js folder. Copy the sencha-touch.css file from SDK to the lib/css folder. Now, create a new file in the sencha-touch-start folder, name it index.html, and add the following code snippet to it: <!DOCTYPE html><html><head><meta charset="utf-8"><title>Hello World</title><script src = "lib/js/sencha-touch-all.js" type="text/javascript"></script><link href="lib/css/sencha-touch.css" rel="stylesheet"type="text/css" /></head><body></body></html> Now create a new file in the sencha-touch-start folder, name it app.js, and add the following code snippet to it: Ext.application({name: 'Hello World',launch: function () {var panel = Ext.create('Ext.Panel', {fullscreen: true,html: 'Welcome to Sencha Touch'});Ext.Viewport.add(panel);}}); Add a link to the app.js file in the index.html page; we created the following link to sencha-touch-all.js and sencha-touch.css: <script src = "app.js" type="text/javascript"></script> Here in the code, Ext.application({..}) creates an instance of the Ext.Application class and initializes our application. The name property defines the name of our application. The launch property defines what an application should do when it starts. This property should always be set to a function inside which we will add our code to initialize the application. Here in this function, we are creating a panel with Ext.create and adding it to Ext.Viewport. Ext. Viewport is automatically created and initialized by the Sencha Touch framework. This is like a base container that holds other components of the application. At this point, your application folder structure should look like this: Now run the application in the browser and you should see the following screen: If your application does not work, please check your web server. It should be turned on, and the steps mentioned earlier should be repeated. Now we will go through some of the most important features and configurations of Sencha Touch. These are required to build real-time Sencha Touch applications. Introduction to layouts Layouts give a developer a number of options to arrange components inside the application. Sencha Touch offers the following four basic layouts: fit hbox vbox card hbox and vbox layouts arrange items horizontally and vertically, respectively. Let's modify our previous example by adding hbox and vbox layouts to it. Modify the code in the launch function of app.js as follows: var panel = Ext.create('Ext.Panel', {fullscreen: true,layout: 'hbox',items: [{xtype: 'panel',html: 'BOX1',flex: 1,style: {'background-color': 'blue'}},{xtype: 'panel',html: 'BOX2',flex: 1,style: {'background-color': 'red'}},{xtype: 'panel',html: 'BOX3',flex: 1,style: {'background-color': 'green'}}]});Ext.Viewport.add(panel); In the preceding code snippet, we specified the layout for a panel by setting the layout: 'hbox' property, and added three items to the panel. Another important configuration to note here is flex. The flex configuration is unique to the hbox and vbox layouts. It controls how much space the component will take up, proportionally, in the overall layout. Here, we have specified flex : 1 to all the child containers; that means the height of the main container will be divided equally in a 1:1:1 ratio among all the three containers. For example, if the height of the main container is 150 px, the height of each child container would be 50 px. Here, the height of the main container would be dependent on the browser width. So, it will automatically adjust itself. This is how Sencha Touch adaptive layout works; we will see this in detail in later sections. If you run the preceding code example in your browser, you should see the following screen: Also, we can change the layout to vbox by setting layout: 'vbox', and you should see the following screen: When we specify a fit layout, a single item will automatically expand to cover the whole space of the container. If we add more than one item and specify only the fit layout, only the first item would be visible at a time. The card layout arranges items in a stack of cards and only one item will be visible at a time, but we can switch between items using the setActiveItem function. We will see this in detail in a later section. Panel – a basic container We have already mentioned the word "panel" in previous examples. It's a basic container component of the Sencha Touch framework. It's basically used to hold items and arrange them in a proper layout by adding the layout configuration. Besides this, it is also used as overlays. Overlays are containers that float over your application. Overlay containers can be positioned relative to some other components. Create another folder in your web server, name it panel- demo, and copy all the files and folders from the sencha-touch-start folder of the previous example. Modify the title in the index.html file. <title>Panel Demo</title> Modify app.js as follows: Ext.application({name: 'PanelDemo',launch: function () {var panel = Ext.create('Ext.Panel', {fullscreen: true,items: [{xtype: 'button',text: 'Show Overlay',listeners: {tap: function(button){var overlay = Ext.create('Ext.Panel', {height: 100,width: 300,html: 'Panel asOverlay'});overlay.showBy(button);}}}]});Ext.Viewport.add(panel);}}); In the preceding code snippet, we have added button as the item in the panel and added listeners for the button. We are binding a tap event to a function for the button. On the tap of the button, we are creating another panel as an overlay and showing it using overlay. showBy(button). Summary This article thus provided us with details on building a Hello World application, which gave you further introduction to the most used components and features of Sencha Touch in real-time applications. Resources for Article : Further resources on this subject: Creating a Simple Application in Sencha Touch [Article] Sencha Touch: Layouts Revisited [Article] Sencha Touch: Catering Form Related Needs [Article]

(For more resources related to this topic, see here.) In the past, the only way that a Windows consumer could acquire the Windows OS was to purchase the installation media on a CD-ROM, floppy disk, or physical computer accessory, which had to be ordered online or bought from a local bricks and mortar store. Now with the recent release of Windows 8, Microsoft is continuing to extend its installation platform to digital media on a large scale. Windows 8 simplifies the process by using a web platform installer called Windows 8 Upgrade Assistant, which makes it easier to download, burn physical copies, and create a backup copy of the installation media. This form of digital distribution allows Microsoft to deploy products at a faster speed to the market, and increase its capacity to meet consumer demands. Getting ready To proceed with this recipe you will need to download Windows 8, so go to http://www.windows.com/buy. How to do it... In the first part of this section we will look into downloading the Windows 8 ISO file. Skip these steps if you have already downloaded the Windows 8 ISO file in advance. Visit the Microsoft website to purchase Windows 8 and then select the option to download the Windows 8 Upgrade Assistant file. Launch the Windows 8 Upgrade Assistant file and proceed with purchasing Windows 8. After completing the transaction, wait while the Windows 8 setup files are downloaded. The estimated download time varies, based on your Internet connection.speed. In addition, you have the option to pause the download and resume it later. Once the download is complete, the Windows 8 Upgrade Assistant will verify the integrity of the download by checking for file corruption and missing files. Wait while the Windows 8 setup gets the files ready to begin the installation. You will see a prompt that says Install Windows 8. Select the Install by creating media radio button. Select ISO file, then click on the Save button. When prompted to select a location to save the ISO file, choose a folder location and type Windows 8 as the filename. Then click on the Save button. When the product key is revealed, write it down and store it somewhere secure. Then click on the Finish button. The following set of instructions explains the details of installing Windows 8 on a newly created virtual machine using VMware Player. These steps are similar to the installation procedures encountered when installing Windows 8 on a physical computer: Open the VMware application by going to Start | All Programs| VMware. Then click on the VMware Player menu item. If you are opening VMware Player for the first time, the VMware Player License Agreement prompt will be displayed. Read the terms and conditions. Select Yes, I accept the terms in the license agreement to proceed to open the VMware Player application. If you select No, I do not accept the terms in the license agreement, you will not be permitted to continue. The Welcome to the New Virtual Machine Wizard screen will be visible. Click on Create a New Virtual Machine on the right side of the window. Select the Installer disc image file (iso): radio button. Then click on the Browse button. Browse to the directory of the Windows 8 ISO image and click on Open. You will see an information icon that says Windows 8 detected. This operating system will use Easy Install. Click on the Next button to continue. Under Easy Install Information, type in the Windows product information and click on Next to continue. You now have the options to: Enter the Windows product key Select the version of Windows to install (Windows 8 or Windows 8 Pro) Enter the full name of the computer Enter a password, which is optional If you do not enter a product key, you will receive a message saying that it can be manually entered later. Enter a new virtual machine name and directory location to install the virtual machine. For example, type Windows 8 VM and then click on the Next button to continue. Enter 16 as the Maximum disk size (GB) and store the virtual disk as a single file. Then click on the Finish button. This is because Windows 8 requires a minimum of 16 GB of free hard drive space. The Windows 8 virtual machine will power on automatically for the first time. At the Ready to Create Virtual Machine prompt, click on the Finish button. Remember that Windows 8 requires a minimum of 16 GB hard disk free space for the 32 bit installation and 20 GB space for the 64 bit installation. VMware will prompt you to install VMware Tools for Windows 2000 and later, click on the Remind Me Later button. The virtual machine will automatically boot up to the Windows 8 setup wizard. Wait until the Windows installation is complete. The virtual machine will reboot several times during this process. You will see various Windows 8 pictorials during the installation; please be patient. Once the installation is complete, your virtual machine will be immediately directed to the Windows 8 home screen. Summary This article introduced you to downloading of the Windows 8 operating system as an ISO, creating a new virtual machine, and installing Window 8 as a virtual machine. Resources for Article: Further resources on this subject: VMware View 5 Desktop Virtualization [Article] Windows 8 with VMware View [Article] Cloning and Snapshots in VMware Workstation [Article]    

(For more resources related to this topic, see here.) One window to rule them all Since we want to give our users the ability to post their messages on multiple social networks at once, it makes perfect sense to keep our whole application in a single window. It will be comprised of the following sections: The top section of the window will contain labels and a text area for message input. The text area will be limited to 140 characters in order to comply with Twitter's message limitation. As the user types his or her message, a label showing the number of characters will be updated. The bottom section of the window will use an encapsulating view that will contain multiple image views. Each image view will represent a social network to which the application will post the messages (in our case, Twitter and Facebook). But we can easily add more networks that will have their representation in this section. Each image view acts as a toggle button in order to select if the message will be sent to a particular social network or not. Finally, in the middle of those two sections, we will add a single button that will be used to publish the message from the text area. Code while it is hot! With our design in hand, we can now move on to create our user interface. Our entire application will be contained in a single window, so this is the first thing we will create. We will give it a title as well as a linear background gradient that changes from purple at the top to black at the bottom of the screen. Since we will add other components to it, we will keep its reference in the win variable: var win = Ti.UI.createWindow({ title: 'Unified Status', backgroundGradient: { type: 'linear', startPoint: { x: '0%', y: '0%' }, endPoint: { x: '0%', y: '100%' }, colors: [ { color: '#813eba'}, { color: '#000' } ] } }); The top section We will then add a new white label at the very top of the window. It will span 90% of the window's width, have a bigger font than other labels, and will have its text aligned to the left. Since this label will never be accessed later on, we will invoke our createLabel function right into the add function of the window object: win.add(Ti.UI.createLabel({ text: 'Post a message', color: '#fff', top: 4, width: '90%', textAlign: Ti.UI.TEXT_ALIGNMENT_LEFT, font: { fontSize: '22sp' } })); We will now move on to create our text area where our users will enter their messages. It will be placed right under the label previously created, occupy 90% of the screen's width, have a slightly bigger font, and have a thick, rounded, dark border. It will also be limited to 140 characters. It is also important that we don't forget to add this newly created object to our main window: var txtStatus = Ti.UI.createTextArea({ top: 37, width: '90%', height: 100, color: '#000', maxLength: 140, borderWidth: 3, borderRadius: 4, borderColor: '#401b60', font: { fontSize: '16sp' } }); win.add(txtStatus); The second label that will complement our text area will be used to indicate how many characters are currently present in the user's message. So, we will now create a label just underneath the text area and assign it a default text value. It will span 90% of the screen's width and have its text aligned to the right. Since this label will be updated dynamically when the text area's value changes, we will keep its reference in a variable named lblCount. As we did with our previous UI components, we will add our label to our main window using the following code: var lblCount = Ti.UI.createLabel({ text: '0/140', top: 134, width: '90%', color: '#fff', textAlign: Ti.UI.TEXT_ALIGNMENT_RIGHT }); win.add(lblCount); The last control from the top section will be our Post button. It will be placed right under the text area and centered horizontally using the following code: var btnPost = Ti.UI.createButton({ title: 'Post', top: 140, width: 150 }); win.add(btnPost); By not specifying any left or right property, the component is automatically centered. This is pretty useful to keep in mind while designing our user interfaces, as it frees us from having to do calculations in order to center something on the screen. Staying within the limits Even though the text area's maxLength property will ensure that the message length will not exceed the limitation we have set, we need to give our users feedback as they are typing their message. To achieve this, we will add an event listener on the change event of our text area. Every time; the text area's content changes, we will update the lblCount label with the number of characters our message contains: txtStatus.addEventListener('change', function(e) { lblCount.text = e.value.length + '/140'; We will also add a condition to check if our user's message is close to reaching its limit. If that is the case, we will change the label's color to red, if not, it will return to its original color: if (e.value.length > 120) { lblCount.color = 'red'; } else { lblCount.color = 'white' } Our last conditional check will be enabling the Post button only if there is actually a message to be posted. This will prevent our users from posting empty messages: btnPost.enabled = !(e.value.length === 0); }); Setting up our Post button Probably the most essential component in our application would be the Post button. We won't be able to post anything online (yet) by clicking on it, as there are things we will still need to add. We will add an event listener for the click event on the Post button. If the on-screen keyboard is displayed, we will call the blur function of the text area in order to hide it: btnPost.addEventListener('click', function() { txtStatus.blur(); Also, we will reset the value to the text area and the character count on the label, so that the interface is ready to enter a new message: txtStatus.value = ''; lblCount.text = '0/140'; }); The bottom section With all our message input mechanisms in place, we will now move on to our bottom section. All components from this section will be contained in a view that will be placed at the bottom of the screen. It will span 90% of the screen's width, and its height will adapt to its content. We will store its reference in a variable named bottomView for later use: var bottomView = Ti.UI.createView({ bottom: 4, width: '90%', height: Ti.UI.SIZE }); We will then create our toggle switches for each social network that our application interacts with. Since we want something sexier than regular switch components, we will create our own switch using a regular image view. Our first image view will be used to toggle the use of Facebook. It will have a dark blue background (similar to Facebook's logo) and will have a background image representing Facebook's logo with a gray background, so that it appears disabled. It will be positioned to the left of its parent view, and will have a borderRadius value of 4 in order to give it a rounded aspect. We will keep its reference in the fbView variable and then add this same image view to our bottom view using the following code: var fbView = Ti.UI.createImageView({ backgroundColor: '#3B5998', image: 'images/fb-logo-disabled.png', borderRadius: 4, width: 100, left: 10, height: 100 }); bottomView.add(fbView); We will create a similar image view (in almost every way), but this time for Twitter. So the background color and the image will be different. Also, it will be positioned to the right of our container view. We will store its reference in the twitView variable and then add it to our bottom view using the following code: var twitView = Ti.UI.createImageView({ backgroundColor: '#9AE4E8', image: 'images/twitter-logo-disabled.png', borderRadius: 4, width: 100, right: 10, height: 100 }); bottomView.add(twitView); Last but not the least, it is imperative that we do not forget to add our bottomView container object into our window. Also, we will open the window so that our users can interact with it using the following code: win.add(bottomView); win.open(); What if the user rotates the device? At this stage, if our user were to rotate the device (to landscape), nothing would happen on the screen. The reason behind this is because we have not taken any action to make our application compatible with the landscape mode. In many cases, this would require some changes to how the user interface is created depending on the orientation. But since our application is fairly simple, and most of our layout relies on percentages, we can activate the landscape mode without any modification to our code. To activate the landscape mode, we will update the orientations section from our tiapp.xml configuration file. It is mandatory to have at least one orientation present in this section (it doesn't matter which one it is). We want our users to be able to use the application, no matter how they hold their device: <iphone> <orientations device="iphone"> <orientation>Ti.UI.PORTRAIT</orientation> <orientation>Ti.UI.UPSIDE_PORTRAIT</orientation> <orientation>Ti.UI.LANDSCAPE_LEFT</orientation> <orientation>Ti.UI.LANDSCAPE_RIGHT</orientation> </orientations> </iphone> By default, no changes are required for Android applications since the default behavior supports orientation changes. There are, of course, ways to limit orientation in the manifest section, but this subject falls out of this article's scope. See it in action We have now implemented all the basic user interface. We can now test it and see if it behaves as we anticipated. We will click on the Run button from the App Explorer tab, as we did many times before. We now have our text area at the top with our two big images views at the bottom, each with the social network's logo. We can already test the message entry (with the character counter incrementing) by clicking on the Post button. Now if we rotate the iOS simulator (or the Android emulator), we can see that our layout adapts well to the landscape mode. To rotate the iOS simulator, you need to use the Hardware menu or you can use Cmd-Left and Cmd-Right on the keyboard. If you are using the Android emulator, there is no menu, but you can change the orientation using Ctrl + F12. The reason this all fits so well is because most of our dimensions are done using percentages. That means that our components will adapt and use the available space on the screen. Also, we positioned the bottom view using the bottom property; which meant that it will stick to the bottom of the screen, no matter how tall it is. There is a module for that Since we don't want to interact with the social network through manual asynchronous HTTP requests, we will leverage the Facebook native module provided with Titanium. Since it comes with Titanium SDK, there is no need to download or copy any file. All we need to do is add a reference (one for each target platform), in the modules section of our tiapp.xml file as follows: <modules> <module platform="android">facebook</module> <module platform="iphone">facebook</module> </modules> Also, we need to add the following property at the end of our configuration file, and replace the FACEBOOK_APPID parameter with the application ID that was provided when we created our app online. <property name="ti.facebook.appid">[FACEBOOK_APPID]</property> Why do we have to reference a module even though it comes bundled with the Titanium framework? Mostly, it is to avoid framework bloat; it is safe to assume that most applications developed using Titanium won't require interaction with Facebook. This is the reason for having it in a separate module that can be loaded on demand. Linking our mobile app to our Facebook app With our Facebook module loaded, we will now populate the necessary properties before making any call to the network. We will need to set the appid property in our code; since we have already defined it as a property in our tiapp.xml file, we can access it through the Properties API. This is a neat way to externalize application parameters, thus preventing us to hardcode them in our JavaScript code: fb.appid = Ti.App.Properties.getString('ti.facebook.appid'); We will also set the proper permissions that we will need while interacting with the server. (In this case, we only want to publish messages on the user's wall): fb.permissions = ['publish_actions']; It is important to set the appid and permissions properties before calling the authorize function. This makes sense since we want Facebook to authorize our application with a defined set of permissions from the get-go. Allowing our user to log in and log out at the click of a button We want our users to be able to connect (and disconnect) at their will from one social network, just by pressing the same view on the screen. To achieve this, we will create a function called toggleFacebook that will have a single parameter: function toggleFacebook(isActive) { If we want the function to make the service active, then we will verify if the user is already logged in to Facebook. If not, we will ask Facebook to authorize the application using the function with the same name. If the parameter indicates that we want to make the service inactive, we will log out from Facebook altogether: if (isActive) { if (!fb.loggedin) { fb.authorize(); } } else { fb.logout(); } } Now, all that we need to do is create an event listener on the click event for our Facebook image view and simply toggle between the two states depending whether the user is logged in or not: fbView.addEventListener('click', function() { toggleFacebook(!fb.loggedIn); }); The authorize function prompts the user to log in (if he or she is not already logged in), and authorize his or her application. It kind of makes sense that Facebook requires user validation before delegating the right to post something on his or her behalf. Handling responses from Facebook We have now completely implemented the Facebook login/logout mechanism into our application, but we still need to provide some feedback to our users. The Facebook module provides two event listeners that allow us to track when our user will have logged in or out. In the login event listener, we will check if the user is logged in successfully. If he or she did, we will update the image view's image property with the colored logo. If there was any error during authentication, or if the operation was simply cancelled, we will show an alert, as given in the following code: fb.addEventListener('login', function(e) { if (e.success) { fbView.image = 'images/fb-logo.png'; } else if (e.error) { alert(e.error); } else if (e.cancelled) { alert("Canceled"); } }); In the logout event listener, we will update the image view's image property with the grayed out Facebook logo using the following code: fb.addEventListener('logout', function(e) { fbView.image = 'images/fb-logo-disabled.png'; }); Posting our message on Facebook Since we are now connected to Facebook, and our application is authorized to post, we can now post our messages on this particular social network. To do this, we will create a new function named postFacebookMessage, with a single parameter, and that will be the message string to be posted: function postFacebookMessage(msg) { Inside this function, we will call the requestWithGraphPath function from the Facebook native module. This function can look fairly complex at first glance, but we will go over each parameter in detail. The parameters are as follows: The Graph API path requested (My feed). A dictionary object containing all of the properties required by the call (just the message). The HTTP method used for this call (POST). The callback function invoked when the request completes (this function simply checks the result from the call. In case of error, an alert is displayed). fb.requestWithGraphPath('me/feed', { message: msg }, "POST", function(e) { if (e.success) { Ti.API.info("Success! " + e.result); } else { if (e.error) { alert(e.error); } else { alert("Unknown result"); } } } ); } We will then update the click event handler for the Post button and call the postFacebookMessage function if the user is logged in to Facebook: btnPost.addEventListener('click', function() { if (fb.loggedIn) { postFacebookMessage(txtStatus.value); } ... }); With this, our application can post messages on our user's Facebook wall. Summary In this article, we learned how to create server-side applications on two popular social networking websites. We learned how to interact with those networks in terms of API and authentication. We also learned how to handle device rotation as well as use the native platform setting Windows. Finally, we covered Titanium menus and activities. Resources for Article: Further resources on this subject: Appcelerator Titanium: Creating Animations, Transformations, and Understanding Drag-and-drop [Article] augmentedTi: The application architecture [Article] Basic Security Approaches [Article]

(For more resources related to this topic, see here.) A computer desktop is normally composed of windows, icons, directories/folders, a toolbar, and some artwork. A window manager handles what the user sees and the tasks that are performed. A desktop is also sometimes referred to as a graphical user interface (GUI). There are many different desktops available for Linux systems. Here is an overview of some of the more common ones. GNOME 2 GNOME 2 is a desktop environment and GUI that is developed mainly by Red Hat, Inc. It provides a very powerful and conventional desktop interface. There is a launcher menu for quicker access to applications, and also taskbars (called panels). Note that in most cases these can be located on the screen where the user desires. The screenshot of GNOME 2 running on Fedora 14 is as follows: This shows the desktop, a command window, and the Computer folder. The top and bottom "rows" are the panels. From the top, starting on the left, are the Applications, Places, and System menus. I then have a screensaver, the Firefox browser, a terminal, Evolution, and a Notepad. In the middle is the lock-screen app, and on the far right is a notification about updates, the volume control, Wi-Fi strength, battery level, the date/time, and the current user. Note that I have customized several of these, for example, the clock. Getting ready If you have a computer running the GNOME 2 desktop, you may follow along in this section. A good way to do this is by running a Live Image, available from many different Linux distributions. The screenshot showing the Add to Panel window is as follows: How to do it... Let's work with this desktop a bit: Bring this dialog up by right-clicking on an empty location on the task bar. Let's add something cool. Scroll down until you see Weather Report, click on it and then click on the Add button at the bottom. On the panel you should now see something like 0 °F. Right-click on it. This will bring up a dialog, select Preferences. You are now on the General tab. Feel free to change anything here you want, then select the Location tab, and put in your information. When done, close the dialog. On my system the correct information was displayed instantly. Now let's add something else that is even more cool. Open the Add to Panel dialog again and this time add Workspace Switcher. The default number of workspaces is two, I would suggest adding two more. When done, close the dialog. You will now see four little boxes on the bottom right of your screen. Clicking on one takes you to that workspace. This is a very handy feature of GNOME 2. There's more... I find GNOME 2 very intuitive and easy to use. It is powerful and can be customized extensively. It does have a few drawbacks, however. It tends to be somewhat "heavy" and may not perform well on less powerful machines. It also does not always report errors properly. For example, using Firefox open a local file that does not exist on your system (that is, file:///tmp/LinuxBook.doc). A File Not Found dialog should appear. Now try opening another local file that does exist, but which you do not have permissions for. It does not report an error, and in fact doesn't seem to do anything. Remember this if it happens to you. KDE desktop The KDE desktop was designed for desktop PCs and powerful laptops. It allows for extensive customization and is available on many different platforms. The following is a description of some of its features. Getting ready If you have a Linux machine running the KDE desktop you can follow along. These screenshots are from KDE running on a Live Media image of Fedora 18. The desktop icon on the far right allows the user to access Tool Box: You can add panels, widgets, activities, shortcuts, lock the screen, and add a lot more using this dialog. The default panel on the bottom begins with a Fedora icon. This icon is called a Kickoff Application Launcher and allows the user to access certain items quickly. These include Favorites, Applications, a Computer folder, a Recently Used folder, and a Leave button. If you click on the next icon it will bring up the Activity Manager. Here you can create the activities and monitor them. The next icon allows you to select which desktop is currently in the foreground, and the next items are the windows that are currently open. Over to the far right is the Clipboard. Here is a screenshot of the clipboard menu: Next is the volume control, device notifier, and networking status. Here is a screenshot of Interfaces and Connections dialog: Lastly, there is a button to show the hidden icons and the time. How to do it... Let's add a few things to this desktop: We should add a console. Right-click on an empty space on the desktop. A dialog will come up with several options; select Konsole. You should now have a terminal. Close that dialog by clicking on some empty space. Now let's add some more desktops. Right-click on the third icon on the bottom left of the screen. A dialog will appear, click on Add Virtual Desktop. I personally like four of these. Now let's add something to the panel. Right-click on some empty space on the panel and hover the mouse over Panel Options; click on AddWidgets. You will be presented with a few widgets. Note that the list can be scrolled to see a whole lot more. For example, scroll over to Web Browser and double-click on it. The web browser icon will appear on the panel near the time. There's more... You can obviously do quite a bit of customization using the KDE desktop. I would suggest trying out all of the various options, to see which ones you like the best. KDE is actually a large community of open source developers, of which KDE Plasma desktop is a part. This desktop is probably the heaviest of the ones reviewed, but also one of the most powerful. I believe this is a good choice for people who need a very elaborate desktop environment. xfce xfce is another desktop environment for Linux and UNIX systems. It tends to run very crisply and not use as many system resources. It is very intuitive and user-friendly. Getting ready The following is a screenshot of xfce running on the Linux machine I am using to write this article: If you have a machine running the xfce desktop, you can perform these actions. I recommend a Live Media image from the Fedora web page. While somewhat similar to GNOME 2, the layout is somewhat different. Starting with the panel on the top (panel 1) is the Applications Menu, following by a LogOut dialog. The currently open windows are next. Clicking on one of these will either bring it up or minimize it depending on its current state. The next item is the Workspaces of which I have four, then the Internet status. To complete the list is the volume and mixer apps and the date and time. The screen contents are mostly self-explanatory; I have three terminal windows open and the File Manager folder. The smaller panel on the bottom of the screen is called panel 2. How to do it... Let's work with the panels a bit: In order to change panel 2 we must unlock it first. Right-click on the top panel, and go to Panel | PanelPreferences. Use the arrows to change to panel 2. See the screenshot below: You can see it is locked. Click on Lock panel to unlock it and then close this dialog. Now go to panel 2 (on the bottom) and right-click on one of the sides. Click on AddNewItems.... Add the applications you desire. There's more... This is by no means an exhaustive list of what xfce can do. The features are modular and can be added as needed. See http://www.xfce.org for more information.

(For more resources related to this topic, see here.) How to do it... Move the cursor on the left ribbon. Select App Directory to open a new window. Select the required app/plugin and integrate available social content apps within HootSuite's web-based dashboard. How it works... Select the App Directory option from HootSuite's left ribbon and it will open a dialogue box with a list of apps that can be integrated with HootSuite. Currently, HootSuite allows you to connect with more than 55 social media networks. Most of the apps are free to connect, however, few premium apps have also been provided. They generally cost around $1.99 to $4.99 per month. Some of the premium apps that can be integrated by all types of users are Statigram, YouTube, Salesforce, and TrendSpottr. HubSpot and SocialFlow are the two premium apps that are only available to Pro and Enterprise HootSuite users. A few commonly used social networking websites can be integrated with HootSuite using app integration, such as Instagram, Tumblr, YouTube, SlideShare, Reddit, Vimeo, Flickr, Evernote, Storify, and StumbleUpon. You can simply click on Install App to integrate them with the HootSuite account. Once integrated, you can create a stream within any of the existing tabs or create new tabs for any specific app. Some of the apps will be standalone, whereas a few will require your login details, such as YouTube and Instagram. There's more... Let's discuss the few less-known, but important, apps that can be used by marketers using HootSuite. Evernote Evernote allows users to capture, organize, and find information from multiple platforms. Evernote is a widely used application because it works on almost all computers, mobile devices, and tablets. The Evernote app allows its users to search content from social networks using keywords. You can view, edit, and share notes with those on your social networks using HootSuite integration. RSS Reader You can add RSS feeds in the RSS Reader app and start receiving articles or information directly on your HootSuite dashboard. You can rename this stream as well so that you can manage multiple streams, receiving information from different sources. If you already have an OPML file, you can import multiple feeds and get a stream of articles. As this app is integrated within HootSuite, it allows you to share the articles on your social networks as well. TrendSpottr TrendSpottr is one of the best apps that we have seen recently. It lets you find trending topics from across social networks. The TrendSpottr app allows you to search for trending content using a keyword/phrase, topic, or type such as trending content, trending hashtags, or trending sources. You can also pick from predefined topics—news, technology, social media, infographic, economy, sports, pop culture, politics, science, and celebrity—or from a list of popular searches. You can share the trending content with your social networks right from this app integrated with HootSuite. YouTube As a digital marketer, you always want to post videos about your products, features, client testimonials, and other visuals to stay connected with your clients. You can connect multiple YouTube accounts at a monthly price of $1.99. Create a separate tab to share and schedule videos from your YouTube account. You can add a title, description, video tags, and privacy settings, and assign a category to your video before uploading. You can also create streams to search and monitor any specific channel, uploader information, or subscriptions. This proves very helpful to share any YouTube video on your other social profiles connected with HootSuite. YouTube Analytics Once you integrate your YouTube account and channel with HootSuite, you can view all analytics from the dashboard itself by integrating the free analytics app (paid app with more insights also available). You can view details about your videos and channels with video-based insights such as engagement levels, sources and countries of traffic, playbacks, demographics and geographic information. You can use all the insights available on the YouTube website. Flickr Just like videos being shared on YouTube, some organizations share pictures of their employees, products, and so on over Flickr. HootSuite offers the ability to integrate using the Flickr app that allows you to view images, upload new pictures, search for pictures, and share them on other connected social media profiles such as Twitter and Facebook. SurveyMonkey As a marketer, you always want to interact with your followers and have an ongoing need to take their feedback. SurveyMonkey is a one-stop solution for feedback from not only your Twitter followers, but also your prospects and customers through e-mails and other online channels. This app allows you to track the created surveys and share them with your social networks. Responses in SurveyMonkey's stream on HootSuite's dashboard are updated on a real-time basis. Once you start receiving responses, you can view responses in a question-summary form that pop up after clicking on the bar graph icon under the Actions label, as seen in the preceding screenshot. You can also see detailed replies by all the respondents after switching to the Individual Responses tab as shown in the following screenshot: SlideShare Marketing, sales, training, and support teams of organizations create PDFs, presentations, and documents to keep their clients or employees abreast with recent happenings. This SlideShare app that gets integrated with HootSuite provides easy access to view complete presentations and search documents on the basis of keywords. It also allows the sharing of such documents over other social media platforms that are connected to HootSuite. List of apps For the updated list of app directories that can be integrated with HootSuite's web-based social profile management tool, you can visit http://hootsuite.com/app-directory. Summary We saw in this article, that almost all the popular social websites can be integrated with HootSuite as apps. This greatly helps marketers in organizing customer interactions with the help of feedbacks and discussions, thus making HootSuite the most preferred choice for managing customer relations. Resources for Article: Further resources on this subject: Social Media in Magento [Article] Social Media for Wordpress: VIP Memberships [Article] Using Media Files – playing audio files [Article]

(For more resources related to this topic, see here.) Accessories Ubuntu provides a number of basic accessory utilities that provide core functionality that you'd expect in a desktop operating system. These include applications, such as an archive manager, backup utility, calculator, and basic text editor. Here we'll introduce some of these applications to give you more of an idea of what you're able to do with your Ubuntu desktop. Archive Manager is a very flexible utility for managing archived data. It supports a range of archive formats and provides you the ability to archive or unarchive data. This application supports archiving with the ZIP, TAR, RAR, and many other popular formats. If you've ever sent a ZIP file, this is the application you'll use to unzip it. If you need to create an archive, perhaps to create a manual backup of some of your data, you can use this application to archive and compress the data to be backed up elsewhere. deja-dup is the included Backup utility. This application provides you with the ability to create automatic backups of your important files on a regular schedule. It supports daily, weekly, and monthly scheduling. The length of time to keep the backups is configurable, as well as the location of the backup. These backups can be automatically shared to cloud storage, FTP, Windows shares, or local-folder locations. With this application, there is no excuse to not have regular backups of your system! The Calculator application is just what you'd expect at first look, a calculator. Upon closer inspection, you'll discover that it supports basic, advanced, financial, and programming modes of calculation. It's lightweight and easy to use, and of course, comes with Ubuntu out of the box. Text Editor is a very flexible utility for everything from taking simple notes to creating computer programs. It isn't a full-blown word processor, but a plain-text text editor. I use Text Editor when I teach beginner programming courses at my local university, as it is flexible enough to support basic programming syntax, while still being simple enough for beginners to use. If you find that you need a basic editor to simply take notes for class, Text Editor is a great place to get started. Customization You'll discover that your Ubuntu desktop is very customizable, allowing you to make your desktop environment your own. You're able to customize the overall theme, desktop backgrounds, fonts, launcher characteristics, and much more. This section will outline a few of the basic things you might want to customize as you're getting started. This will include desktop look and feel, online account configuration, and even hardware and driver support. Customizing the look and feel of your Ubuntu desktop is done within the Appearance application. Here you'll be able to customize the desktop background, theme, and launcher settings. Select from the many included desktop wallpaper backgrounds and see a preview on the virtual display. Change your theme within the theme drop-down menu. You can also optionally customize the launcher icon size and overall behavior. The default theme is called Ambiance. This provides the darker look that you see now. If you prefer a lighter theme, you might try the Radiance theme, which is an opposite look and feel to Ambiance. I like to configure my desktop with Ambiance, relatively small launcher icons, and an auto-hiding bar. Feel free to customize your desktop however you like. Experiment with different themes and settings until you find the look and feel you prefer. In regards to hardware support, Ubuntu provides a system to check for and install the drivers for proprietary hardware. This generally includes popular video cards from ATI or NVIDIA as well as some wireless network cards. While these drivers are not open source, Ubuntu can automatically detect the need for them, and handle the installation for you. This will give you better support for hardware not normally supported by open source operating systems. Launch the Additional Drivers menu item, and let Ubuntu scan your hardware. If it detects a need for proprietary drivers, it will prompt you, and walk you through the installation. If nothing is found, it simply means that you are already using open source drivers, and that your hardware is already fully supported. Also available within the customization section is the Broadcast Accounts and Broadcast Settings applications. This is where you can configure your Twitter and Facebook chat accounts as well as preferences. Once configured, these accounts will be available directly from the status bar in the top right of your screen. If you click on the icon that looks like an envelope, you should see an entry for broadcast. This is where the broadcast accounts are integrated into your Ubuntu system, allowing you to update your status, and view and reply to messages from friends and family without needing to keep Facebook or Twitter open in a web browser. Games Ubuntu has both basic and more advanced gaming options available. Some of the games are things you'd expect, such as Solitaire or Minesweeper. Also included are tile-matching game Mahjongg and the number puzzle Sudoku. These are sure to provide hours of gaming fun. If you're interested in other gaming options, quite a few more are available in the Ubuntu Software Center. For those that are looking for gaming options beyond what is in the Ubuntu Software Center, Ubuntu is also supported by the Steam gaming platform. Historically, Steam has only supported Windows and Apple; however, Ubuntu was selected as the first (and currently only) Linux platform to be officially supported by Steam. The following section will describe how to install Steam on your Ubuntu system and gain access to the Steam supported games for Ubuntu. First, launch the Ubuntu Software Center and search for Steam in the search window. This should provide a number of results. You'll want to select the one labeled The ultimate entertainment platform. Select this option from the list, and click on Buy. You'll be prompted with and need to agree to the Software License Agreement. This will take you to the Ubuntu single sign-on page, where you'll need to log in or create a new account. If you have not yet registered for an Ubuntu account, you'll need to register here. This takes only a few minutes, and is completely free. Once you have created and/or logged into your account, the installation will continue. When the installation is finished, a window will appear notifying you that you'll need to Start Steam to complete the installation. Click on Start Steam to continue. This will be followed by a Steam Installation Agreement, which you'll need to agree to. Check the box I have read and accept the terms, and click on OK. At this point, Steam will launch and begin downloading any available Steam updates. This may take a few minutes depending on your Internet connection. From this point, you'll have the option to create a new Steam account or sign into an existing account. If you've played Steam games on other platforms, you should be able to use your existing credentials here. If you're new to Steam and want to get started, create a new account, and continue. From here on you're ready to play Steam games! Summary In this article, we learned about different accessories, such as archive manager, backup utility, calculator, and basic text editor. Then, we learned how to make an operating system our own by customizing it with things that includes desktop look and feel, online account configuration, and even hardware and driver support. Lastly, we also learned about the part you will love the most that is games available on Ubuntu, such as Solitaire, Minesweeper, Mahjongg, and Sudoku. So, have fun while learning about one of the best operating systems available out there: Ubuntu. Resources for Article: Further resources on this subject: Making a Complete yet Small Linux Distribution [Article] Linux Shell Script: Logging Tasks [Article] Notifications and Events in Nagios 3.0-part1 [Article]

(For more resources related to this topic, see here.) Altering Apache Lucene scoring With the release of Apache Lucene 4.0 in 2012, all the users of this great, full text search library, were given the opportunity to alter the default TF/IDF based algorithm. Lucene API was changed to allow easier modification and extension of the scoring formula. However, that was not the only change that was made to Lucene when it comes to documents score calculation. Lucene 4.0 was shipped with additional similarity models, which basically allows us to use different scoring formula for our documents. In this section we will take a deeper look at what Lucene 4.0 brings and how those features were incorporated into ElasticSearch. Setting per-field similarity Since ElasticSearch 0.90, we are allowed to set a different similarity for each of the fields we have in our mappings. For example, let's assume that we have the following simple mapping that we use, in order to index blog posts (stored in the posts_no_similarity.json file): { "mappings" : { "post" : { "properties" : { "id" : { "type" : "long", "store" : "yes", "precision_step" : "0" }, "name" : { "type" : "string", "store" : "yes", "index" : "analyzed" }, "contents" : { "type" : "string", "store" : "no", "index" : "analyzed" } } } } } What we would like to do is, use the BM25 similarity model for the name field and the contents field. In order to do that, we need to extend our field definitions and add the similarity property with the value of the chosen similarity name. Our changed mappings (stored in the posts_similarity.json file) would appear as shown in the following code: { "mappings" : { "post" : { "properties" : { "id" : { "type" : "long", "store" : "yes", "precision_step" : "0" }, "name" : { "type" : "string", "store" : "yes", "index" : "analyzed", "similarity" : "BM25" }, "contents" : { "type" : "string", "store" : "no", "index" : "analyzed", "similarity" : "BM25" } } } } } And that's all, nothing more is needed. After the preceding change, Apache Lucene will use the BM25 similarity to calculate the score factor for the name and contents fields. In case of the Divergence from randomness and Information based similarity model, we need to configure some additional properties to specify the behavior of those similarities. How to do that is covered in the next part of the current section. Default codec properties When using the default codec we are allowed to configure the following properties: min_block_size: It specifies the minimum block size Lucene term dictionary uses to encode blocks. It defaults to 25. max_block_size: It specifies the maximum block size Lucene term dictionary uses to encode blocks. It defaults to 48. Direct codec properties The direct codec allows us to configure the following properties: min_skip_count: It specifies the minimum number of terms with a shared prefix to allow writing of a skip pointer. It defaults to 8. low_freq_cutoff: The codec will use a single array object to hold postings and positions that have document frequency lower than this value. It defaults to 32. Memory codec properties By using the memory codec we are allowed to alter the following properties: pack_fst: It is a Boolean option that defaults to false and specifies if the memory structure that holds the postings should be packed into the FST. Packing into FST will reduce the memory needed to hold the data. acceptable_overhead_ratio: It is a compression ratio of the internal structure specified as a float value which defaults to 0.2. When using the 0 value, there will be no additional memory overhead but the returned implementation may be slow. When using the 0.5 value, there can be a 50 percent memory overhead, but the implementation will be fast. Values higher than 1 are also possible, but may result in high memory overhead. Pulsing codec properties When using the pulsing codec we are allowed to use the same properties as with the default codec and in addition to them one more property, which is described as follows: freq_cut_off: It defaults to 1. The document frequency at which the postings list will be written into the term dictionary. The documents with the frequency equal to or less than the value of freq_cut_off will be processed. Bloom filter-based codec properties If we want to configure a bloom filter based codec, we can use the bloom_filter type and set the following properties: delegate: It specifies the name of the codec we want to wrap, with the bloom filter. ffp: It is a value between 0 and 1.0 which specifies the desired false positive probability. We are allowed to set multiple probabilities depending on the amount of documents per Lucene segment. For example, the default value of 10k=0.01, 1m=0.03 specifies that the fpp value of 0.01 will be used when the number of documents per segment is larger than 10.000 and the value of 0.03 will be used when the number of documents per segment is larger than one million. For example, we could configure our custom bloom filter based codec to wrap a direct posting format as shown in the following code (stored in posts_bloom_custom.json file): { "settings" : { "index" : { "codec" : { "postings_format" : { "custom_bloom" : { "type" : "bloom_filter", "delegate" : "direct", "ffp" : "10k=0.03, 1m=0.05" } } } } }, "mappings" : { "post" : { "properties" : { "id" : { "type" : "long", "store" : "yes", "precision_step" : "0" }, "name" : { "type" : "string", "store" : "yes", "index" : "analyzed", "postings_format" : "custom_bloom" }, "contents" : { "type" : "string", "store" : "no", "index" : "analyzed" } } } } } NRT, flush, refresh, and transaction log In an ideal search solution, when new data is indexed it is instantly available for searching. At the first glance it is exactly how ElasticSearch works even in multiserver environments. But this is not the truth (or at least not all the truth) and we will show you why it is like this. Let's index an example document to the newly created index by using the following command: curl -XPOST localhost:9200/test/test/1 -d '{ "title": "test" }' Now, we will replace this document and immediately we will try to find it. In order to do this, we'll use the following command chain: curl –XPOST localhost:9200/test/test/1 -d '{ "title": "test2" }' ; curl localhost:9200/test/test/_search?pretty The preceding command will probably result in the response, which is very similar to the following response: {"ok":true,"_index":"test","_type":"test","_id":"1","_version":2}{ "took" : 1, "timed_out" : false, "_shards" : { "total" : 5, "successful" : 5, "failed" : 0 }, "hits" : { "total" : 1, "max_score" : 1.0, "hits" : [ { "_index" : "test", "_type" : "test", "_id" : "1", "_score" : 1.0, "_source" : { "title": "test" } } ] } } The first line starts with a response to the indexing command—the first command. As you can see everything is correct, so the second, search query should return the document with the title field test2, however, as you can see it returned the first document. What happened? But before we give you the answer to the previous question, we should take a step backward and discuss about how underlying Apache Lucene library makes the newly indexed documents available for searching. Updating index and committing changes The segments are independent indices, which means that queries that are run in parallel to indexing, from time to time should add newly created segments to the set of those segments that are used for searching. Apache Lucene does that by creating subsequent (because of write-once nature of the index) segments_N files, which list segments in the index. This process is called committing. Lucene can do this in a secure way—we are sure that all changes or none of them hits the index. If a failure happens, we can be sure that the index will be in consistent state. Let's return to our example. The first operation adds the document to the index, but doesn't run the commit command to Lucene. This is exactly how it works. However, a commit is not enough for the data to be available for searching. Lucene library use an abstraction class called Searcher to access index. After a commit operation, the Searcher object should be reopened in order to be able to see the newly created segments. This whole process is called refresh. For performance reasons ElasticSearch tries to postpone costly refreshes and by default refresh is not performed after indexing a single document (or a batch of them), but the Searcher is refreshed every second. This happens quite often, but sometimes applications require the refresh operation to be performed more often than once every second. When this happens you can consider using another technology or requirements should be verified. If required, there is possibility to force refresh by using ElasticSearch API. For example, in our example we can add the following command: curl –XGET localhost:9200/test/_refresh If we add the preceding command before the search, ElasticSearch would respond as we had expected. Changing the default refresh time The time between automatic Searcher refresh can be changed by using the index.refresh_interval parameter either in the ElasticSearch configuration file or by using the update settings API. For example: curl -XPUT localhost:9200/test/_settings -d '{ "index" : { "refresh_interval" : "5m" } }' The preceding command will change the automatic refresh to be done every 5 minutes. Please remember that the data that are indexed between refreshes won't be visible by queries. As we said, the refresh operation is costly when it comes to resources. The longer the period of refresh is, the faster your indexing will be. If you are planning for very high indexing procedure when you don't need your data to be visible until the indexing ends, you can consider disabling the refresh operation by setting the index.refresh_interval parameter to -1 and setting it back to its original value after the indexing is done. The transaction log Apache Lucene can guarantee index consistency and all or nothing indexing, which is great. But this fact cannot ensure us that there will be no data loss when failure happens while writing data to the index (for example, when there isn't enough space on the device, the device is faulty or there aren't enough file handlers available to create new index files). Another problem is that frequent commit is costly in terms of performance (as you recall, a single commit will trigger a new segment creation and this can trigger the segments to merge). ElasticSearch solves those issues by implementing transaction log. Transaction log holds all uncommitted transactions and from time to time, ElasticSearch creates a new log for subsequent changes. When something goes wrong, transaction log can be replayed to make sure that none of the changes were lost. All of these tasks are happening automatically, so, the user may not be aware of the fact that commit was triggered at a particular moment. In ElasticSearch, the moment when the information from transaction log is synchronized with the storage (which is Apache Lucene index) and transaction log is cleared is called flushing. Please note the difference between flush and refresh operations. In most of the cases refresh is exactly what you want. It is all about making new data available for searching. From the opposite side, the flush operation is used to make sure that all the data is correctly stored in the index and transaction log can be cleared. In addition to automatic flushing, it can be forced manually using the flush API. For example, we can run a command to flush all the data stored in the transaction log for all indices, by running the following command: curl –XGET localhost:9200/_flush Or we can run the flush command for the particular index, which in our case is the one called library: curl –XGET localhost:9200/library/_flush curl –XGET localhost:9200/library/_refresh In the second example we used it together with the refresh, which after flushing the data opens a new searcher. The transaction log configuration If the default behavior of the transaction log is not enough ElasticSearch allows us to configure its behavior when it comes to the transaction log handling. The following parameters can be set in the elasticsearch.yml file as well as using index settings update API to control transaction log behavior: index.translog.flush_threshold_period: It defaults to 30 minutes (30m). It controls the time, after which flush will be forced automatically even if no new data was being written to it. In some cases this can cause a lot of I/O operation, so sometimes it's better to do flush more often with less data being stored in it. index.translog.flush_threshold_ops: It specifies the maximum number of operations after which the flush operation will be performed. It defaults to 5000. index.translog.flush_threshold_size: It specifies the maximum size of the transaction log. If the size of the transaction log is equal to or greater than the parameter, the flush operation will be performed. It defaults to 200 MB. index.translog.disable_flush: This option disables automatic flush. By default flushing is enabled, but sometimes it is handy to disable it temporarily, for example, during import of large amount of documents. All of the mentioned parameters are specified for an index of our choice, but they are defining the behavior of the transaction log for each of the index shards. Of course, in addition to setting the preceding parameters in the elasticsearch.yml file, they can also be set by using Settings Update API. For example: curl -XPUT localhost:9200/test/_settings -d '{ "index" : { "translog.disable_flush" : true } }' The preceding command was run before the import of a large amount of data, which gave us a performance boost for indexing. However, one should remember to turn on flushing when the import is done. Near Real Time GET Transaction log gives us one more feature for free that is, real-time GET operation, which provides the possibility of returning the previous version of the document including non-committed versions. The real-time GET operation fetches data from the index, but first it checks if a newer version of that document is available in the transaction log. If there is no flushed document, data from the index is ignored and a newer version of the document is returned—the one from the transaction log. In order to see how it works, you can replace the search operation in our example with the following command: curl -XGET localhost:9200/test/test/1?pretty ElasticSearch should return the result similar to the following: { "_index" : "test", "_type" : "test", "_id" : "1", "_version" : 2, "exists" : true, "_source" : { "title": "test2" } } If you look at the result, you would see that again, the result was just as we expected and no trick with refresh was required to obtain the newest version of the document.

(For more resources related to this topic, see here.) Principles for UI/UX There are many dos and don'ts in Windows Phone UI development. It is good to remember that we have a screen with a limited size where the elements should be placed comfortably. Fast and fluid This is the main goal of Windows Phone UX. Starting with the phone menu, we can switch between tiles and application lists; if we touch an element action it is performed very fast. We have to remember while creating our own software about providing responsivity to user interaction, even if we need to load some data or connect to a server, the user has to be informed about loading. Going through our application, the user should feel that he or she controls and can touch every element. Many controls provide animation out of the box and we need to use it; we need to impress our users while seeing motion in our application. The application has to be alive! Grid system The following design pattern provides consistency and high UX to Windows Phone users. It helps in organizing the application elements. A grid system will provide unity across applications and will make our application look similar to the Windows Store application. Talking about the grid layout, we mean arranging the content using grid lines. As we can see, the grid is where the application design starts. Each square is located 12 pixels from the other square. Single square has 25 x 25 pixels. In order to provide the best user experience to our application, we need to ensure that the elements are arranged appropriately. Looking at the left-hand side of the image, we find that each big tile contains 6 x 6 squares with 12 pixels margins. Windows is one When using a grid system and other design patterns for Windows Phone, porting to Windows Store will be possible and can be done more easily. Unfortunately at the moment, there are no common markets for Windows Phone application and Windows Store (applications for Windows 8 and Windows RT). The current solution is to create the application in a way that it allows portability to other platforms, such as separating the application's logic from UI. Even then some specific changes have to be done. Controls design best practices Button Use a maximum of two words in the Button content; it can be dynamically set but should never be more than two words To define content use system font Use a minimum height of 40 pixels CheckBox A CheckBox text should present a clear choice to the user If there are many choices, use the ScrollViewer and StackPanel control It is recommended to use single or a maximum of two lines of content text If the meaning of checkbox is not clear, use RadioButton or ListBox HyperlinkButton Don't place two hyperlinks close to each other because it will make it difficult to select either one Hyperlink text should not be longer than two words If some action can be reached by taping in text content, use HyperlinkButton instead of Button Image Size (resolution) of the picture has to be really close or identical to the Image control size Use gestures if it is possible The Image controls displays JPEG or PNG images Provide good quality images-non pixelated ListBox Use ListBox with long list of items; for smaller lists use RadioButton ListBox should be responsive so that it provides an immediate visual reaction for the user action Use at least 12 pixels height with sans-serif font MediaElement Do not show too many controls on one page Do not allow for a situation when more than one media (audio or video) is playing simultaneously Panorama The Panorama control handles only portrait orientation If you are using ApplicationBar with Panorama, make sure that the ApplicationBar control is in minimized mode Do not use too many sections (PanoramaItems); use a maximum of 5 sections to avoid torturing the user with swiping Panorama title can contain image and/or text Use system font; an exception is when your brand uses custom font First PanoramaItem should contain a left-aligned title For section title use plain text Do not use Pivot in PanoramaItem and Panorama in PivotItem Horizontal scrolling can be difficult because of the default behavior of Panorama; use vertical scrolling instead Good quality background photography makes for a very good users' impression, but ensure that all content is readable Background should be low contrast and dark Background image can be maximally 1024 x 800 pixels and minimally 480 x 800 pixels to provide good performance Pivot Do not place Pivot in PanoramaItem Use a maximum of 4 Pivot items Each PivotItem should not contain completely different actions; their functionality should be related Do not use input controls because it disrupts the Pivot flick, if you want to create a form with editing controls, use a separate page that will contain the form  Do not use controls that need swipe or scroll inside Panorama like Map, ToggleButton, or Slider because the Pivot default gesture handling it, can make it difficult for the user to use them ProgressBar It is highly recommended to use a label that describes the state of the ProgressBar control-loading, launching, and failed RadioButton Avoid customization Provide 2 short words as content text, with at least 12 pixels height maximally Use ListBox if this control has more than 10 decisions to make Bring user's attention to the selected RadioButton control by making inactive those that are not selected ScrollViewer Avoid creating a situation where a user has too much content to scroll Slider Make sure that the Slider control is the appropriate size for comfortable use Do not use Slider as a progress indicator Do not put Slider too close to the edge of the screen because it can be difficult to select a value It shouldn't be used within Panorama or Pivot because Slider uses dragging gestures, whose usage is difficult in those containers TextBlock Make sure that the text in the TextBlock control looks clear and is readable TextBox To improve the user's experience, update the application content when the user enters text into TextBox; for example while filtering data It is not possible to scroll rich text inputs When it is likely that the user will enter a new value into TextBox, select all content on focus LongListSelector LongListSelector is used for a large number of data items Use at least 12 pixel Sans serif font Fonts From the GUI and UX point of view, it is critical to make text clear and legible. Entire text should be properly contrasted to the background. The font used in Windows Phone, is Sans serif, which is widely used in web and mobile applications. The Sans serif font type has many fonts, which one should we use? There is no simple answer for that, it depends on the control and context in which we use the text. However, it is recommended to use Segoe UI, Calibri, or Cambria font types. Segoe UI: This is best used in UI elements such as buttons, checkboxes, datepickers, and others like these. Calibri: This is best used for input and content text such as e-mail messages. When using this font it is good to set the font size to 13. Cambria: This font type is recommended for articles or any other big pieces of text, depending on content section, we can use 9, 11, 20 pt Cambria font. An example of each of the these fonts is as follows: 11 pt Segoe UI font 13 pt Calibri font 11 pt Cambria font Tiles and notifications My friend who is the owner of a company that creates mobile applications, once said to me that 50% of an application's success depends on how nice and good looking the icon/tile is. After thinking about it, I imagine he was right. The tile is the first thing that a user sees when starting to use our application (remember what I said about first impression?). The Windows Phone tile is not only a static icon that represents our application, but it can be live and show some simplified content as well. A default tile is a static icon and can display some information such as message count after it updates, and it returns to the default tile only after another update. An application tile can be pinned to the Start screen and set in one of 3 sizes: A small tile is built from 3 x 3 grid units. It is half the width and height of medium tile. It was introduced in Windows Phone 8 and 7.8 update of Windows Phone 7. Only a medium-size tile was available in Windows Phone 7. Every application pinned to the Start screen starts with medium tile. Along with the small tile, a large tile was introduced in Windows Phone 8. Why we should use the tile that is updating (live tile)? Because the tile is the front door of our application and if it gives some notification to user it really says, "Hey! Come here and see what I've got for you!". An updated tile assures the users that our application is fresh and active, even if it has not been run for some time. If we want to allow the user to pin our application in large/wide tile, we should provide a wide image, point it in the application manifest, and mark the Supports wide size option. There are some good practices which are worth following. If our application has the content that is refreshed at least once every few days and can be interesting for the user, we should enable our application to use wide tile; if not it is not necessary. Forget about the wide tile if the application doesn't use notifications. There are three available tile templates that will help us to create tiles as follows: Iconic template which is mainly used for e-mails, messaging, RSS, and social networking apps. Flip templates that are used in an application gives the user a lot of information like weather application. Cycle template for galleries and photo applications that cycles 1 to 9 images in a tile—applicable only for medium and wide tile. Bindings Basically, binding is a mechanism that the whole MVVM pattern relays on. It is very powerful and is the "glue" between the view and the exposed fields and commands. The functionality that we want to implement is shown in the following diagram: Model We are going to use the Model class for storing data about users. public class UserModel:INotifyPropertyChanged { private string name {get;set; public string Name { get; set { name = value; RaisePropertyChanged(); } } public string LastName { get; set{(…)} } public string Gender { get; set{(…)} } public DateTime DateOfBirth { get; set{(…)} } public event PropertyChangedEventHandler PropertyChanged; (…) } One thing that we still have to implement is the property changed event subscription for all fields within this UserModel class. ViewModel Now, UserModel will be wrapped into UserViewModel. Our ViewModel will also implement the INotifyPropertyChanged interface for updating View when the VieModels object change. public class UserViewModel:INotifyPropertyChanged { public UserModel CurrentUser { get; set; } public string FullName { get { if (this.CurrentUser != null) { return string.Format("{0} {1}", this.CurrentUser.Name, this.CurrentUser.LastName); } return ""; } } public List<string> ListOfPossibleGenders = new List<string>(){"Male","Female"}; (…) } As we can see, UserModel is wrapped in two ways: the first is wrapping the entire Model and some properties that are transformed into FullName. The FullName property contains Name and LastName that comes from UserModel object. View I'm going to create a view, piece by piece, to show how things should be done. At the beginning, we should create a new UserControl object called UserView in the Views folder. We will do almost everything now in XAML; so, we have to open the UserView.xaml file and add a few things. In the root node, we have to add namespace for our ViewModel folder. Because of this line, our ViewModels will be accessible in the XAML code. <UserControl.DataContext> <models:UserViewModel/> </UserControl.DataContext> It sets DataContext of our view in XAML and has its equivalent in DataContext. If we wish to set DataContext in the code behind, we have to go to the constructor in the .cs file. public UserView() { InitializeComponent(); var viewModel = new SampleViewModel(); this.DataContext = viewModel; } A better approach is to define the ViewModel instance in XAML because we have intellisense support in binding expressions for fields that are public in ViewModel and the exposed model. As we can see, ViewModel contains the CurrentUser property that will store and expose the user data to the view. It has to be public, and thing that is missing here is the change notification in the CurrentUser setter. However, we already know how to do that so it is not described. <StackPanel> <TextBlock Text="Name"></TextBlock> <TextBox Name="txtName" Text="{ Binding CurrentUser.Name, Mode=TwoWay }"> </TextBox> <TextBlock Text="Lastname"></TextBlock> <TextBox Name="txtLastName" Text="{ Binding CurrentUser.LastName , Mode=TwoWay}"> </TextBox> <TextBlock Text="Gender"></TextBlock> <ListBox Name="lstGender" ItemsSource="{ Binding ListOfPossibleGenders}" SelectedItem="{Binding CurrentUser.Gender, Mode=TwoWay}"> </ListBox> </StackPanel> The preceding example shows how to set binding using the exposed model as well as list or property that was implemented directly in ViewModel. We made all these things without any code behind line! This is really good because our sample is testable and is very easy to write unit tests We use the TwoWay binding mode that automatically populates the control value and then the edit control value of the ViewModel property also gets updated. Summary Creating complex applications that will be intuitive and simple to use is really hard without the knowledge of the UI and UX principles that were described in this article. We covered a huge part of XAML— bindings. Resources for Article : Further resources on this subject: Windows 8 with VMware View [Article] How to Build a RSS Reader for Windows Phone 7 [Article] Introducing the Windows Store [Article]

(For more resources related to this topic, see here.) Reducing planned and unplanned downtime Whether we are talking about a highly available and critically productive environment or not, any planned or unexpected downtime means financial losses. Historically, solutions that could provide high availability and redundancy were costly and complex. With the virtualization technologies available today, it becomes easier to provide higher levels of availability for environments where they are needed. With VMware products, and vSphere in particular, it's possible to do the following things: Have higher availability that is independent of hardware, operating systems, or applications Choose a planned downtime for many maintenance tasks, and shorten or eliminate them Provide automatic recovery in case of failure Planned downtime Planned downtime usually happens during hardware maintenance, firmware or operating system updates, and server migrations. To reduce the impact of planned downtime, IT administrators are forced to schedule small maintenance windows outside the working hours. vSphere makes it possible to dramatically reduce the planned downtime. With vSphere, IT administrators can perform many maintenance tasks at any point in time as it allows downtime elimination for many common maintenance operations. This is possible mainly because workloads in a vSphere can be dynamically moved between different physical servers and storage resources without any service interruption. The main availability capabilities that are built into vSphere allow the use of HA and redundancy features, and are as follows: Shared storage: Storage resources such as Fibre Channel, iSCSI, Storage Area Network (SAN), or Network Access Storage (NAS) help eliminate the single points of failure. SAN mirroring and replication features can be used to have fresh copies of the virtual disk at disaster recovery sites. Network interface teaming: This feature provides tolerance for individual network card failures. Storage multipathing: This helps to tolerate storage path failures. vSphere vMotion® and Storage vMotion functionalities allow the migration of VMs between ESXi hosts and their underlying storage without service interruption, as shown in the following figure: In other words, vMotion is the live migration of VMs between ESXi hosts, and Storage vMotion is the live migration of VMs between storage LUNs. In both cases, VM retains its network and disk connection. With vSphere 5.1 and the later versions, it's possible to combine vMotion with Storage vMotion into a single migration that simplifies administration. The entire process takes less than two seconds on a GB network. vMotion keeps track of the ongoing memory transaction while memory and system states get copied to the target host. Once copying is done, vMotion suspends the source VM, copies the transactions that happened during the process to the target host, and resumes the VM on the target host. This way, vMotion ensures transaction integrity. vSphere requirements for vMotion vSphere requirements for vMotion are as follows: All the hosts must have the following features: They should be correctly licensed for vMotion Have access to the shared storage Use a GB Ethernet adapter for vMotion, preferably a dedicated one The VMkernel port group is configured for vMotion with the same name (the name is case sensitive) Have access to the same subnets Must be members of all the vSphere distributed switches that VMs use for networking Use jumbo frames for best vMotion performance All the virtual machines that need to be vMotioned must have the following features: Shouldn't use raw disks if migration between storage LUNs is needed Shouldn't use devices that are not available on the destination host (for example, a CD drive or USB devices not enabled for vMotion) Should be located on a shared storage resource Shouldn't use devices connected from the client computer Migration with vMotion Migration with vMotion happens in three stages: vCenter server verifies that the existing VM is in a stable state and that the CPU on the target host is compatible with the CPU this VM is currently using vCenter migrates VM state information such as memory, registers, and network connections to the target host The virtual machine resumes its activities on the new host VMs with snapshots can be vMotioned regardless of their power state as long as their files stay on the same storage. Obviously, this storage has to be accessible for both the source and destination hosts. If migration involves moving configuration files or virtual disks, the following additional requirements apply: Both the source and destination hosts must be of ESX or ESXi version 3.5 or later All the VM files should be kept in a single directory on a shared storage resource To vMotion a VM in vCenter, right-click on a VM and choose Migrate… as shown in the following screenshot: This opens a migration wizard where you can select whether it's going to migrate between hosts or storage or both. The Change hostoption is the standard vMotion, and Change datastore is the Storage vMotion. As you can see, the Change both host and datastore option is not available because this VM is currently running. As mentioned earlier, vSphere 5.1 and later support vMotion and Storage vMotion in one transaction. In the next steps, you are able to choose the destination as well as the priority for this migration. Multiple VMs can be migrated at the same time if you make multiple selections in the Virtual Machines tab for the host or the cluster. VM vMotion is widely used to perform host maintenance such as upgrading the ESX operating system, memory, or any other configuration changes. When maintenance is needed on a host, all the VMs can be migrated to other hosts and this host can be switched into the maintenance mode. This can be accomplished by right-clicking on the host and selecting Enter Maintenance Mode. Unplanned downtime Environments, especially critical ones, need to be protected from any unplanned downtime caused by possible hardware or application failures. vSphere has important capabilities that can address this challenge and help to eliminate unplanned downtime. These vSphere capabilities are transparent to the guest operating system and any applications running inside the VMs; they are also a part of the virtual infrastructure. The following features can be configured for VMs in order to reduce the cost and complexity of HA. More detail on these features will be given in the following sections of this article. High availability (HA) vSphere's HA is a feature that allows a group of hosts connected together to provide high levels of availability for VMs running on these hosts. It protects VMs and their applications in the following ways: In case of ESX server failure, it restarts VMs on the other hosts that are members of the cluster In case of guest OS failure, it resets the VM If application failure is detected, it can reset a VM With vSphere HA, there is no need to install any additional software in a VM. After vSphere HA is configured, all the new VMs will be protected automatically. The HA option can be combined with vSphere DRS to protect against failures and to provide load balancing across the hosts within a cluster The advantages of HA over traditional failover solutions are listed in the VMware article at http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.avail.doc%2FGUID-CB46CEC4-87CD-4704-A9AC-058281CFD8F8.html. Creating a vSphere HA cluster Before HA can be enabled, a cluster itself needs to be created. To create a new cluster, right-click on the datacenter object in the Hosts and Clusters view and select New Cluster... as shown in the following screenshot: The following prerequisites have to be considered before setting up a HA cluster: All the hosts must be licensed for vSphere HA. ESX/ESXi 3.5 hosts are supported for vSphere HA with the following patches installed; these fix an issue involving file locks: ESX 3.5: patch ESX350-201012401-SG and prerequisites ESXi 3.5: patch ESXe350-201012401-I-BG and prerequisites At least two hosts must exist in the cluster. All the hosts' IP addresses need to be assigned statically or configured via DHCP with static reservations to ensure address consistency across host reboots. At least one network should exist that is shared by all the hosts, that is, a management network. It is best practice to have at least two. To ensure VMs can run on any host, all the hosts should also share the same datastores and virtual networks. All the VMs must be stored on shared, and not local, storage. VMware tools must be installed for VM monitoring to work. Host certificate checking should be enabled. Once all of the requirements have been met, vSphere HA can be enabled in vCenter under the cluster settings dialog. In the following screenshot, it appears as PRD-CLUSTER Settings: Once HA is enabled, all the cluster hosts that are running and are not in maintenance mode become a part of HA. HA settings The following HA settings can also be changed at the same time: Host monitoring status is enabled by default Admission control is enabled by default Virtual machine options (restart priority is Medium by default and isolation response by default is set to Leave powered on) VM monitoring is disabled by default Datastore heartbeating is selected by vCenter by default More details on each of these settings can be found in the following sections of this article. Host monitoring status When a HA cluster is created, an agent is uploaded to all the hosts and configured to communicate with other agents within the cluster. One of the hosts becomes the master host, and the rest become slave hosts. There is an election process to choose the master host, and the host that mounts more datastores has an advantage in this election. In cases where we have a tie, the host with the lexically-highest Managed Object ID(MOID) is chosen. MOID, also called MoRef ID, is a value generated by vCenter for each object: host, datastore, VM, and so on. It is guaranteed to be unique across the infrastructure managed by this particular vCenter server. When it comes to the election process for choosing the master host, a host with ID 99 will have higher priority than a host with ID 100. If a master host fails or becomes unavailable, a new election process is initiated. Slave hosts monitor whether the VMs are running locally and report to the master host. In its turn, the master host communicates with vCenter and monitors other hosts for failures. Its main responsibilities are listed as follows: Monitoring the state of the slave hosts and in case of failure, identifying which VMs must be restarted Monitoring the state of all the protected VMs and restarting them in case of failure Managing a list of hosts and protected VMs Communicating with vCenter and reporting the cluster's health state Host availability monitoring is done through a network heartbeat exchange, which happens every second by default. In cases where we lose network heartbeats with a host, before declaring it as failed, the master host checks whether this host communicates with any of the existing datastores using datastore heartbeats and responds to pings sent to its management IP address or not. The master host detects the following types of host failure: Type of failure Network heartbeats ICMP ping Datastore heartbeats Lost connectivity to the master host - + + Network isolation - - + Failure - - - If host failure is detected, the host's VMs will be restarted on other hosts. Host network isolation happens when a host is running but doesn't see any traffic from vSphere HA agents, which means that it's disconnected from the management network. Isolation is handled as a special case of failure in VMware HA. If a host becomes network isolated, the master host continues to monitor this host and the VMs running on it. Depending on the isolation settings chosen for individual VMs, some of them may be restarted on another host. The master host has to communicate with vCenter, therefore, it can't be in the isolation mode. Once that happens, a new master host will be elected. When network isolation happens, certain hosts are not able to communicate with vCenter, which may result in configuration changes not having effect on certain parts of the infrastructure. If a network infrastructure is configured correctly and has redundant network paths, isolation should happen rarely. Datastore heartbeating Datastore heartbeating was introduced in vSphere 5. In the previous versions of vSphere, once a host became unreachable through the management network, HA always initiated VM restart, even if the VMs were still running. This, of course, created unnecessary downtime and additional stress to the host. Datastore heartbeating allows HA to make a distinction between hosts that are isolated or partitioned and hosts that have failed, which adds more stability to the way HA works. vCenter server selects a list of datastores for heartbeat verification to maximize the number of hosts that can be verified. It uses a selection algorithm designed to select datastores that are connected to the highest number of hosts. This algorithm attempts to choose datastores that are hosted on different storage arrays or NFS servers. It also prefers VMFS-formatted LUNs over NFS-hosted datastores. vCenter selects datastores for heartbeating in the following scenarios: When HA is enabled If a new datastore is added If the accessibility to a datastore changes By default, two datastores are selected. This is the minimum amount of datastores needed. It can be changed using the das.heartbeatDsPerHost parameter under Advanced Settings for up to five datastores. The PRD-CLUSTER Settings dialog box can be used to verify or change the datastores selected for heartbeating, as shown in the following screenshot: It is recommended, however, to let vCenter choose the datastores. Only the datastores that are mounted to more than one host are available in the list. Datastore heartbeating leverages the existing VMFS filesystem locking mechanism. There is a so-called heartbeat region that exists on each datastore and is updated as long as the lock on a file exists. A host updates the datastore's heartbeat region if it has at least one file opened on this volume. HA creates a file for datastore heartbeating purposes only to make sure there is at least one file opened on a volume. Each host creates its own file and HA to be able to determine whether an unresponsive host still has connection to a datastore, and simply checks whether the heartbeat region has been updated or not. By default, an isolation response is triggered after 5 seconds for the master host and after approximately 30 seconds if the host was a slave in vSphere 5. This time difference occurs because of the fact that if the host was a slave, it would need to go through the election process to determine whether there are any other hosts that exist, or whether the master host is simply down. This election starts within 10 seconds after the slave host has lost its heartbeats. If there is no response for 15 seconds, the HA agent on this host elects itself as the master. The isolation response time can be increased using the das.config.fdm.isolationPolicyDelaySec parameter under Advanced Settings. This is, however, not recommended as it increases the downtime when a problem occurs. If a host becomes a master in a cluster with more than one host and has no slaves, it continuously starts checking whether it's in the isolation mode or not. It keeps doing so until it becomes a master with slaves or connects to a master as a slave. At this point, the host will ping its isolation address to determine whether the management network is available again. By default, the isolation address is a gateway configured for the management network. This option can be changed using the das.isolationaddress[X] parameter under Advanced Settings. [X] takes values from 1 to 10 and allows configuration of multiple isolation addresses. Additionally, the das.usedefaultisolationaddress parameter can be used to indicate whether the default gateway address should be used as an isolation address or not. This parameter should be set to False if the default gateway is not configured to respond to the ICMP ping packets. Generally, it's recommended to have one isolation address for each management network. If this network uses redundant paths, the isolation address should always be available under normal circumstances. In certain cases, a host may be isolated, that is, not accessible via the management network but still able to receive election traffic. This host is called partitioned. Have a look at the following figure to gain more insight about this: When multiple hosts are isolated but can still communicate with each other, it's called a network partition. This can happen for various reasons; one of them is when a cluster spans multiple sites over a metropolitan area network. This is called the stretched cluster configuration. When a cluster partition occurs, one subset of hosts is able to communicate with the master while the other is not. Depending on the isolation response selected for VMs, they may be left running or restarted. When a network partition happens, the master election process is initiated within the subset of hosts that loses its connection to the master. This is done to make sure that the host failure or isolation results in appropriate action on the VMs. Therefore, a cluster will have multiple masters; each one in a different partition as long as the partition exists. Once the partition is resolved, the masters are able to communicate with each other and discover the multiplicity of master hosts. Each time this happens, one of them becomes a slave. The hosts' HA state is reported by vCenter through the Summary tab for each host as shown in the following screenshot: This is done under the Hosts tab for cluster objects as shown in the following screenshot: Running (Master) indicates that HA is enabled and the host is a master host. Connected (Slave) means that HA is enabled and the host is a slave host. Only the running VMs are protected by HA. Therefore, the master host monitors the VM's state and once it changes from powered off to powered on, the master adds this VM to the list of protected machines. Virtual machine options Each VM's HA behavior can be adjusted under vSphere HA settings or in the Virtual Machine Options option found in the PRD-CLUSTER Settings page as shown in the following screenshot: Restart priority The restart priority setting determines which VMs will be restarted first after the host failure. The default setting is Medium. Depending on the applications running on a VM, it may need to be restarted before other VMs, for example, if it's a database, a DNS, or a DHCP server. It may be restarted after others if it's not a critical VM. If you select Disabled, this VM will never be restarted if there is a host failure. In other words, HA will be disabled for this VM. Isolation response The isolation response setting defines HA actions against a VM if its host loses connection to the management network but is still running. The default setting is Leave powered on. To be able to understand why this setting is important, imagine the situation where a host loses connection to the management network and at the same time or shortly afterwards, to the storage network as well—a so-called split-brain situation. In vSphere, only one host can have access to a VM at a time. For this purpose, the .vmdk file is locked and there is an additional .lck file present in the same folder where .vmdk file is stored. As HA is enabled, VMs will fail over to another host, however, their original instances will keep running on the old host. Once this host comes out of isolation, we will end up with two copies of VMs. Therefore, the isolated host will not have access to the .vmdk file as it's locked. In vCenter, however, this VM will look as if it is flipping between two hosts. With the default settings, the original host is not able to reacquire the disk locks and will be querying the VM. HA will send a reply instead which allows the host to power off the second running copy. If the Power Off option is selected for a VM under the isolation response settings, this VM will be immediately stopped when isolation occurs. This can cause inconsistency with the filesystem on a virtual drive. However, the advantage of this is that VM restart on another host will happen more quickly, thus reducing the downtime. The Shut down option attempts to gracefully shut down a VM. By default, HA waits for 5 minutes for this to happen. When this time is over, if the VM is not off yet, it will be powered off. This timeout is controlled by the das.isolationshutdowntimeout parameter under the Advanced Settings option. VM must have VMware tools installed to be able to shut down gracefully. Otherwise, the shutdown option is equivalent to power off. VM monitoring Under VM Monitoring, the monitoring settings of individual applications can be adjusted as shown in the following screenshot: The default setting is Disabled. However, VM and Application Monitoring can be enabled so that if the VM heartbeat (VMware tool's heartbeat) or its application heartbeat is lost, the VM is restarted. To avoid false positives, the VM monitoring service also monitors VM's I/O activity. If a heartbeat is lost and there was no I/O activity (by default during the last 2 minutes), VM is considered as unresponsive. This feature allows you to power cycle nonresponsive VMs. I/O interval can be changed under the advanced attribute settings (for more details, check the HA Advanced attributes table later in this section). Monitoring sensitivity can be adjusted as well. Sensitivity means the time interval between the loss of heartbeats and restarting of the VM. The available options are listed in the table from the VMware documentation article available at http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.avail.doc_50%2FGUID-62B80D7A-C764-40CB-AE59-752DA6AD78E7.html. To avoid repeating VM resets by default, they will be restarted only three times during the reset period. This can be changed in the Custom mode as shown in the following screenshot: In order to be able to monitor applications within a VM, they need to support VMware application monitoring. Alternatively, you can download the appropriate SDK and set up customized heartbeats for the application that needs to be monitored. Under Advanced Options, the following vSphere HA behaviors can be set. Some of them have already been mentioned in sections of this article. The following screenshot shows the Advanced Options (vSphere HA) window where advanced HA options can be added and set to specific values: vSphere HA advanced options are listed in the article from VMware documentation available at http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.avail.doc_50%2FGUID-E0161CB5-BD3F-425F-A7E0-B F83B005FECA.html. This mentioned article also lists the options that are not supported in vCenter 5. You will get an error message if you try to add one of them. Also, the options will be deleted after being upgraded from the previous versions. Admission control Admission control ensures there are sufficient resources available to provide failover protection as and when VM resource reservations are kept. Admission control is available for the following: Hosts Resource pools vSphere HA Admission control can only be disabled for vSphere HA. The following screenshot shows PRD-CLUSTER Settings with the option to disable admission control: Examples of actions that may not be permitted because of insufficient resources are as follows: Power on a VM Migrate a VM to another host, cluster, or resource pool Increase CPU or memory reservation for a VM Admission control policies There are three possible types of admission control policies available for HA configuration that are as follows: Host failure cluster tolerates: When this option is chosen, HA ensures that a specified number of hosts can fail, but sufficient resources will still be available to accommodate all the VMs from these hosts. The decision to either allow or deny an operation is based on the following calculations: Slot size: A hypothetical VM that has the largest amount of memory and CPU that is assigned to an existing VM in the environment. For example, for the following VMs, the slot size will be 4 GHz and 6 GB: VM CPU RAM VM1 4 GHz 2 GB VM2 2 GHz 4 GB VM3 1 GHz 6 GB Host capacity: It gives the number of slots each host can hold based on the resources available for VMs; not the total host memory and CPU. For example, for the previous slot size, the host capacity will be as given in the following table: Host CPU RAM Slots Host1 4 GHz 128 GB 1 Host2 24 GHz 6 GB 1 Host3 8 GHz 14 GB 2 Cluster failover capacity: This gives the number of hosts that can fail before there aren't enough slots left to accommodate all the VMs. For example, for previous hosts with 1 host failure policy, the failover capacity is 2 slots. In case of Host3 failure (host with larger capacity), the cluster is left with only two slots. But if the current failover capacity is less than the allowed limit, admission control disallows the operation. For example, if we are running two VMs and need to power the third one, it will be denied as the cluster capacity is two and it may not be able to accommodate three VMs. This option is probably not the best one for an environment that has VMs with significantly more of resources assigned than the rest of the VMs. The Host failure cluster tolerates option can be used when all cluster hosts are sized pretty much equally. Otherwise, if you use this option, then excessive capacity is reserved such that the cluster tolerates the largest host failure. When this option is used, VM reservations should be kept similar across the cluster as well. Because vCenter uses the slot sizes model to calculate capacity, and the slot size is based on the largest reservation, having VMs with a large reservation will again result in additional unnecessary capacity being reserved. Percentage of cluster resources: With this policy enabled, HA ensures that a specified percentage of resources are reserved for failover across all the hosts. It also checks that there are at least two hosts available. The calculation happens as follows: The total resource requirement for all the running VMs is calculated. For example, for three VMs in the previous table, the total requirement will be 7 GHz and 12 GB. The total available host resources are calculated. For the previous example, the total is 34 GHz and 148 GB. The current CPU and memory failover capacity for the cluster is calculated as follows: CPU: (1-7/34)*100%=79% RAM: (1-12/148)*100%=92% If the current CPU and memory capacity is less than allowed, the operation is denied. With such different hosts from the example, the CPU and RAM capacity should be configured carefully to avoid a situation when, for example, the host with most amount of RAM fails and the other hosts are not able to accommodate all the VMs because of memory resources. Therefore, RAM should be configured at 87 percent based on the two smallest hosts (#2 and #3) and not 30% based on the number of hosts in the environment: [1-(6+14)/148]*100%=87% In other words, if the host with 128 GB fails, we need to make sure that the total resources needed by the VMs are less than the sum of 6 GB and 14 GB, which is only 13 percent of the total cluster's 148 GB. Therefore, we need to make sure that in all instances, the VMs use only 13 percent of the RAM or that the cluster has 87 percent of RAM that is free. Specified failover hosts: With this policy enabled, HA keeps the chosen failover hosts reserved, doesn't allow the powering on or migrating of any VMs to this host, and restarts VMs on this host only when failure occurs. If for some reason, it's not possible to use a designated failover host to restart the VMs, HA will restart them on other available hosts. It is recommended to use the Percentage of cluster resources reserved option in most cases. This option offers more flexibility in terms of host and VM sizing than other options. HA security and logging vSphere HA configuration files for each host are stored on the host's local storage and are protected by the filesystem permissions. These files are only available to the root user. For security reasons, ESXi 5 hosts log HA activity only to syslog. Therefore, logs are placed at a location where syslog is configured to keep them. Log entries related to HA are prepended with fdm, which stands for fault domain manager. This is what the vSphere HA ESX service is called. Older versions of ESXi write HA activity to fdm logfiles in /var/log/vmware/fdm stored on the local disk. There is also an option to enable syslog logging on these hosts. Older ESX hosts are able to save HA activity only in the fdm local logfile in /var/log/vmware/. HA agent logging configuration also depends on the ESX host version. For ESXi 5 hosts, the logging options that can be configured via the Advanced Options tab under HA are listed in the article under the logging section available at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2033250. The das.config.log.maxFileNum option causes ESXi 5 hosts to maintain two copies of the logfiles: one is a file created by the Version 5 logging mechanism, and the other one is maintained by the pre-5.0 logging mechanism. After any of these options are changed, HA needs to be reconfigured. The following table provides log capacity recommendations according to VMware for environments of different sizes based on the requirement to keep one week of history: Size Minimum log capacity per host in MB 40 VMs in total with 8 VMs per host 4 375 VMs in total with 25 VMs per host 35 1,280 VMs in total with 40 VMs per host 120 3,000 VMs in total with 512 VMs per host 300 These are just recommendations; additional capacity may be needed depending on the environment. Increasing the log capacity involves specifying the number of rotations together with the file size as well as making sure there is enough space on the storage resource where the logfiles are kept. The vCenter server uses the vpxuser account to connect to the HA agents. When HA is enabled for the first time, vCenter creates this account with a random password and makes sure the password is changed periodically. The time period for a password change is controlled by the VirtualCenter.VimPasswordExpirationInDays parameter that can be set under the Advanced Settings option in vCenter. All communication between vCenter and HA agents, as well as agent-to-agent traffic, is secured with SSL. Therefore, for vSphere HA, it's necessary that each host has verified SSL certificates. New certificates require HA to be reconfigured. It will also be reconfigured automatically if a host has been disconnected before the certificate is replaced. SSL certificates are also used to verify election messages so if there is a rogue agent running, it will only be able to affect the host it's running on. This issue, if it occurs, is reported to the administrator. HA uses TCP/8182 and UDP/8182 ports for communication between agents. These ports are opened and closed automatically by the host's firewall. This helps to ensure that these ports are open only when they are needed. Using HA with DRS When vSphere HA restarts VMs on a different host after a failure, the main priority is the immediate availability of VMs. Based on CPU and memory reservations, HA determines which host to use to power the VMs on. This decision is based, of course, on the available capacity of the host. It's quite possible that after all the VMs have been restarted, some hosts become highly loaded while others are relatively lightly loaded. DRS is the load balancing and failover solution that can be enabled in vCenter for better host resource management. vSphere HA, together with DRS, is able to deliver automatic failover and load balancing solutions, which may result in a more balanced cluster. However, there are a few things to consider when it comes to using both features together. In a cluster with DRS, HA, and the admission control enabled; VMs may not be automatically evacuated from a host entering the maintenance mode. This occurs because of resources reserved for VMs that need to be restarted. In this case, the administrator needs to migrate these VMs manually. Some VMs may not fail over because of resource constraints. This can happen in one of the following cases: HA admission control is disabled and DPM is enabled, which may result in insufficient capacity available to perform failover as some hosts may be in the standby mode and therefore, fewer hosts would be available. VM to host affinity rules limit hosts where certain VMs can be placed. Total resources are sufficient but fragmented across multiple hosts. In this case, these resources can't be used by the VMs for failover. DPM is in the manual mode that requires an administrator's confirmation before a host can be powered on from the standby mode. DRS is in the manual mode, and an administrator's confirmation may be needed so that the migration of VMs can be started. What to expect when HA is enabled HA only restarts a VM if there is a host failure. In other words, it will power on all the VMs that were running on a failed host placed on another member of the cluster. Therefore, even with HA enabled, there will still be a short downtime for VMs that are running on faulty hosts. In fast environments, however, VM reboot happens quickly. So if you are using some kind of monitoring system, it may not even trigger an alarm. Therefore, if a bunch of VMs have been rebooted unexpectedly, you know there was an issue with one of the hosts and can review the logs to find out what the issue was. Of course, if you have set up vCenter notifications, you should get an alert. If you need VMs to be up all the time even if the host goes down, there is another feature that can be enabled called Fault Tolerance.