Maadili World is based on a book by Nicolai Peitersen called "The Ethical Economy". Nicolai is a Danish economist who worked for the Danish Central Bank, and later Morgan Stanley in London. He moved to Chengdu, Sichuan, China, and I happened to meet him walking in a park in Southwest Chengdu one day a little over a year ago.
Although the book is several years old now, a Chinese version was just published in 2014. The book talks about how the valuation of companies has changed over the years. Companies used to be valued on their sales, and their brick and mortar assets (ie... their profits and the value of their salable assets). That started to change when companies began building brands, and outsourcing and distributed manufacturing became the norm. Now, companies like Apple (currently the highest valued company in the world), own few if any factories but are valued highly.
In the world of social networking, a new factor was added to how companies are valued: Their Ethical Values. People in the green movement have been particularly effective at changing company values by boycotting polluters and buying from non-polluters. Ethical value investing has become main stream, and there is little doubt that the publics' perception of a companys ethical values affect both their sales and their valuation in the stock market.
Maadili World is our attempt at quantifying and measuring ethical values worldwide and feeding that information to companies so that they can better adjust their business practices to reflect the ethical values of their consumers, shareholders, lenders and the general public.
We believe strongly that companies who want to prosper need to continually adjust their ethical practices, and we feel that Maadili World will give the people a voice, and the companies the information they need to improve.
BG Double Adsense
You can use BG Double Adsense the same way you use the other Joomla! Adsense modules. IE - put your Google Adsense code into the module and display it the module position. BUT.... if you use a fixed width on your website (which most of us seem to do), BG Adsense can display extra Google Adsense "windows" alongside your normal body content, if the user's browser window is big enough.
Optimizing Your MySQL database
First of all, I highly recommend Rackspaces' Cloud Servers. We've been using them for many months now, and they are great to work with. It's absolutely painless to resize your server, add or delete RAM, and the bandwidth charges are incredibly reasonable.In our case, all of our websites are relatively low volume, so we have never tested the limits of the cloud servers but we do have a lot of websites running on our server, and we have the additional complications of running the web server, mail server and databases all on the same machine.
Of course, like most people we don't want to pay more than we need to for our web presence, so we run a Cloud Server and we've sized it to only have 1 Gig of RAM. Now, when you think about running the web server, mail server and the databases all on that configuration, you can see that we have to be a little creative to have good performance. In addition, one of our websites (NoCrappyApps.com) is integrated with the Android Market and we run several daemons constantly to keep the data as fresh as possible, so this poor little server is really being pushed a bit.
Now, with our configuration, we determined that the maximum RAM we could allow MySQL to use was 384M, and we currently have 22 databases in that MySQL instance. Most of the web sites are Joomla 1.5 or Joomla 1.6 sites, and many of them have over 200 databases tables. We happen to be a little obsessed with knowing what our users are using (because that's how we know which features are popular), so we log almost everything, and then run statistics routines every night to give ourselves and our users up to date information.
Obviously, we will have to add more memory to the server in the next few months, but Rackspace gives us options there also. We could just resize our existing Cloud Server to give it 2G of RAM, but for the same price, Rackspace gives us the option of adding another server with 1G of RAM. That has the advantage of being able to move all the databases to the new server, and moving the databases means that we can configure the new server specifically for MySQL and the old server configurations can be changed so that it is optimized for just the web server and mail server. We'll probably move to having the second server although it will be a little more setup work in the beginning. We use an Ubuntu server, and Rackspace makes it easy to setup and configure a new server. Actually, I should mention that Rackspace has really good documentation on setting up servers. I've been able to setup a new server and have it completely configured in less than 2 hours, and at the time, I had very little experience with cloud servers. In the beginning, I actually just setup about 3 or 4 test servers and then deleted them. I think Rackspace charged me about 4 cents per server (their charges are based on a per server per hour basis, so you only have to pay for what you actually use... and did I mention that their charges are incredibly low?).
Ok... so how the heck are we running 15 websites, MySQL with 22 databases, a web server and a mail server all on 1G of RAM? Well.. the first thing we had to do was configure Apache not to hog all the memory. Apache can easily use the entire 1 GIG of RAM and the mail server likes quite a bit of RAM also (all 15 websites have unlimited mail accounts). Once we had those under control, we had the 384M that we thought MySQL could use.
The first thing we had to do was optimize all the SQL. In our case, we're using Joomla 1.5 or 1.6 for all the websites, but Joomla 1.6 was missing a lot of indexes and even Joomla 1.5 doesn't have all the indexes it should. So... we setup MySQL to log the slow queries (set log_slow_queries for the file you want to log to and we set long_query_time = 2 (seconds) in my.cnf). Then every day, I spent about an hour checking the slow queries and figuring out which indexes to add to speed them up. Of course, I have to rewrite some queries to get the performance I wanted.This is an ongoing task, but I now only need to spend about an hour a week on it. I also monitor the MySQL error log.
I should mention also that you should not be using the mysql engine for your Joomla databases. Switch it to mysqli (the I stands for "improved") instead, or just go directly to InnoDB. InnoDB of course, is much better for large databases and tables that do a lot of read and writes simultaneously because it has row locking while the mysql and mysqli engines do table locking (not so good, although smaller databases or low volume databases won't notice so much). At this point, we are still using mysqli because of our memory constraints, so we turned the skip_InnoDb flag on so InnoDb doesn't load and use up some of our RAM even though it's not being used.
Now... you need more information on the innards of MySQL to do more. There are some links here that might help, and you can download a perl script here that is quite helpful in making suggestions for improvements.
NOTE - DO NOT JUST BLINDLY follow any recommendations without fully understanding what they do.
Of course, eveyone is looking for a magic formula to just tell them what settings to change and there are my.cnf files on the internet for large, small and medium databases. If you're just getting started these are ok, but you still need to go through each line in your my.cnf file and make sure you understand why it's set where it is... and make the changes you need.
You need to monitor your actual server use and then make changes based on what's actually happening... and you need to do this continually... this is not a set-and-forget thing. You can run SQL queries to monitor your server. Use the "SHOW STATUS" command to see what your server status, and "SHOW VARIABLES" to see your settings. Or just use Navicat (the paid version) and it has a Server monitor that does the same thing. You don't have to pay for tools but it is nice to be able to see it in a GUI form rather than a command-line format.
Some of the variables I've found to be very important are "query_cache_limit" and "query_cache_size". Read about them and understand them, and you need to experiment and know how your MySQL instance is actually being used to get them set correctly (TIP - the MySQL defaults cannot be relied on, they won't be right for your use). Essentially, the "query_cache_size" is the amount of RAM you allocate for querying caching. NOTE that the only queries that can be cached are queries like "SELECT * FROM some_table". It only caches static queries (queries that don't change), but those are most of your lookup tables which are the ones used the most frequently. You want to get most of your static queries into cache WITHOUT using any more RAM than you need to.
Then you want to play with the "table_open_cache" variable (early versions of MySQL before 5.1 had this set MUCH too low). The MySQL tuning script will help here, but the key status variable to watch to see if you're got it right are "Open_tables", "Opened_tables", "Open_files" and "Opened_files". You want the ratio of "Opened_files" to "Open_files" to be very low (not many "Opened_files), and the same with tables (very few "Opened_tables" compared to "Open_tables".
Also monitor your "key_blocks_used" and "key_blocks_unused" carefully. You don't want too many "key_blocks_unused" or you are just wasting RAM. On the other hand, you don't want the MySQL server to be continually having to go to the disk for it's "key_read_requests" either. Check the ratio of "key_read_requests" (the number of times the server needed a key) to the "key_reads" (the number of times the key was not in cache memory so the server needed to go to the disc drive to find it). The number of "key_reads" compared to the number of "key_read_requests" should be very low (probably much less than 5% if everything is setup properly, and hopefully lower than that). Of course, the variable to concentrate on here is "key_cache_block_size". Increase it if you have too many "key_reads" and decrease it is you have too many "key_blocks_unused".
Anyway that's a brief summary of the most important issues... and I've purposely not given too much detail on them because you need to understand them... AND know how your MySQL server is ACTUALLY being used to get them right. There is NO magic formula unless you simply add dozens of GIG's of RAM and let everything use mega memory if it wants. We can't afford that, but if you can, go for it. Until I win the lottery, I'll have to be content with actually knowing what my server does and how to set it up for that :).
Approximately two weeks ago (as of early Feb, 2011) we started work on a major project. It will most likely become an all consuming project for at least 6 months. The project is a website, Android App and supporting services for MaxHomeValue.com. MaxHomeValue is new entry into the home renovations market and we expect it will become a major player in the industry over the next 2 years or so.
MaxHomeValue gives Home Owners the ability to find good, reliable contractors for any project they have involving home renovations. The Home Owner can manage the project themselves or MaxHomeValue will manage it for them. Contractors can bid on projects, manage them and easily communicate with the Home Owner.
We've already started putting up publicly available information and Homeowners, Contractors looking for work, Realtors and the other group can register although the other account management features will not be available for a little over a month from now.
Check the MaxHomeValue site out, and let us know what you think about it! Just remember... it will be a work in progress until at least the middle of May, 2011.
No Crappy Apps
If you've been keeping up with the Android World, you know that Android has been a tremendously successful cell phone platform. It's good to see.... I decided to concentrate on programming for Android over two years ago, and at the time I was fairly sure in my own mind that Android would do well... but it was certainly not guaranteed. I was working on my first Android App BEFORE there was even one cell phone running Android. I then pre-ordered and bought one of the first Android phones (the original T-Mobile G1) and received it on the first day on the first release.
Fast forward to today, and Android powered cell phones are being activated at the rate of over 300,000 a day. There are so many cell phone running Android that I've lost track of how many they are, and there are well over 140,000 Android programs available for download. Android has truly been the most successful launch of a new cell phone operating system EVER.
Of course, things haven't been quite as smooth for many Android Developers. The Google Android Market is a black hole of despair for most Android Developers. When I release a new Android App, I'm lucky if the app stays on the first page of the "Just-in" list for more than a couple of hours. Sometimes not even that long. And with over 140,000 apps and only 32 categories it's almost impossible for a new app to get noticed at all, even if it's a very good app. When I released my first "PriceBunny" app (a barcode scanner that parsed Amazon and eBay for prices), it stayed on the "Just-In" first page for a couple of days and could be easily found for over a week. In addition it showed up in the "Most Popular" in it's category almost right away. Now... when I release a new App I'm lucky if it ever shows up in the "Most Popular" because there are an average of over 4,000 apps in every category and some have over 7,000 apps, and most of them are terrible quality and it makes it hard to find the good apps.
Well.. about 2 months ago, I set out to cure the problem. I started my own Android Market called "No Crappy Apps" (for Android). All the way I developed some sophisticated software algorithms to detect SPAM apps and SPAM comments. Of course... as I am an Android Programmer I also developed a cell phone application, so users can now find good apps for their cell phone FROM their cell phone :). No Crappy Apps™ also developed a "Developer Support" index to help weed out those developers that release a crappy app, and then don't bother to support it and make it better. And we built ways to feature better quality apps and make them known to Android users.
Check out No Crappy Apps
I think you will agree that it's MUCH better than the Android Market... Let me know.