首先，你要有一个该平台的运行环境（象MTK,展讯都提供一套完整的软件方案）。经过简单的调试，该运行环境编译通过，并且可以运行出WIn32模拟器。

其次，找出手机软件的运行入口。所有的手机启动过程如下：开机 —〉初始化硬件设备—-〉初始化软件（全局变量，读取nv数据等）—-〉开机动画，搜寻网络，Sim卡等—>Idle界面。在vc 工程下，你可以搜寻”Init”，”Initialize”,”start”，”task”等关键字，可能会找到很多c文件包含这些关键字。然后，你可以根据文件名，以及文件所属的路径，排除大部分搜索结果。在剩下的每个搜索结果处，加一个断点。按“F5”调试，程序会停在某个断点。这个断点向上看看，可以找到手机软件的运行入口。沿着这个断点跟下去，你就可以发现APP初始化，读取nv,Sim ,显示Animation等等……

第三，简单了解Idle。根据文件路径以及文件名，我们可以确定哪几个文件属于Idle 。一般来说，各个平台的Idle程序都比较乱，因为Idle修改的人多，上面Icon,状态特多。在Idle文件里查找 “create”“start”“entry”等关键字，通过设置断点，可以定位Idle的入口及其出口。Idle不要细看，只要知道Idle的入口，以及从Idle如何进入MainMenu就行了。

第四，详细了解MainMenu。MainMenu是所有模块中比较简单的一个，程序代码也比较少。只要了解了MenuMain，我觉得各位就可以在该平台上修改一些简单的Bug了。

第五，自己动手写一个简单的App,在App中尝试使用各种控件。至于如何使用控件，各位可以先看看哪些模块用到这些控件，把相关程序拷贝过来，稍加修改即可。

第六，尝试添加修改图片字符串资源。

第七，查找关键字“Timer”,看看程序如何使用Timer.

第八，理解消息传递，窗口调用，信息保存等等。

到此为止，你对一个新平台的MMI至少掌握了70%，至于其它的一些细枝末节，以后工作中再慢慢细抠。
 

部分转自 http://blog.csdn.net/fengye245/archive/2010/03/24/5412749.aspx

先是准备工作,需要java5和apache-forrest-0.8

基本上也是问题一堆,因为ubuntu9.10开始不支持java5所以装java5-sun-jdk稍微麻烦了一下

可以参考这篇文章 http://blog.csdn.net/sunrock/archive/2010/04/29/5542989.aspx

修改源改成9.04的源然后安装java5-sun-jdk

接着

安装apache-forrest-0.8

http://forrest.apache.org/mirrors.cgi For UNIX operating systems: apache-forrest-0.8.tar.gz
解压后 我放在 /home/cloud/apache-forrest-0.8

直接下载来hadoop-0.20.2+228.tar.gz 解压缩即可

然后修改3个地方

1.修改$HADOOP_HOME/src/contrib/build-contrib.xml
增加一行：<property name=”eclipse.home” location=”/usr/lib/eclipse”/>

2.修改 $HADOOP_HOME/src/contrib/eclipse-plugin/src/java/org/apache/hadoop/eclipse/launch/HadoopApplicationLaunchShortcut.java
注释掉原来的//import org.eclipse.jdt.internal.debug.ui.launcher.JavaApplicationLaunchShortcut;
改为import org.eclipse.jdt.debug.ui.launchConfigurations.JavaApplicationLaunchShortcut;

3.修改$HADOOP_HOME/build.xml

增加

<property name=”java5.home” location=”/usr/lib/jvm/java-1.5.0-sun-1.5.0.19/”/>
<property name=”forrest.home” location=”/home/cloud/apache-forrest-0.8/”/>

这2行

然后ant compile

ant package 应该是没问题了

生成的eclipse plugin是在$HADOOP_HOME/build/contrib/eclipse-plugin/

或者直接去 http://hadoop-eclipse-plugin.googlecode.com/files/hadoop-0.20.3-dev-eclipse-plugin.jar 下载吧

http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-eventual-consistency-and-the-cap-theorem/fulltext

Let’s start with a discussion of what causes errors in databases. The following is at least a partial list:

1) Application errors. The application performed one or more incorrect updates. Generally, this is not discovered for minutes to hours thereafter. The database must be backed up to a point before the offending transaction(s), and subsequent activity redone.

2) Repeatable DBMS errors. The DBMS crashed at a processing node. Executing the same transaction on a processing node with a replica will cause the backup to crash. These errors have been termed Bohr bugs. [2]

3) Unrepeatable DBMS errors. The database crashed, but a replica is likely to be ok. These are often caused by weird corner cases dealing with asynchronous operations, and have been termed Heisenbugs [2]

4) Operating system errors. The OS crashed at a node, generating the “blue screen of death.”

5) A hardware failure in a local cluster. These include memory failures, disk failures, etc. Generally, these cause a “panic stop” by the OS or the DBMS. However, sometimes these failures appear as Heisenbugs.

6) A network partition in a local cluster. The LAN failed and the nodes can no longer all communicate with each other.

7) A disaster. The local cluster is wiped out by a flood, earthquake, etc. The cluster no longer exists.

A network failure in the WAN connecting clusters together. The WAN failed and clusters can no longer all communicate with each other.

很经典的8种分类,甚至包括了地震和洪水…

原文转自 http://highscalability.com/blog/2010/5/3/mocospace-architecture-3-billion-mobile-page-views-a-month.html

This is a guest post by Jamie Hall, Co-founder & CTO of MocoSpace, describing the architecture for their mobile social network. This is a timely architecture to learn from as it combines several hot trends: it is very large, mobile, and social. What they think is especially cool about their system is: how it optimizes for device/browser fragmentation on the mobile Web; their multi-tiered, read/write, local/distributed caching system; selecting PostgreSQL over MySQL as a relational DB that can scale.

MocoSpace is a mobile social network, with 12 million members and 3 billion page views a month, which makes it one of the most highly trafficked mobile Websites in the US. Members access the site mainly from their mobile phone Web browser, ranging from high end smartphones to lower end devices, as well as the Web. Activities on the site include customizing profiles, chat, instant messaging, music, sharing photos & videos, games, eCards and blogs. The monetization strategy is focused on advertising, on both the mobile and Websites, as well as a virtual currency system and a handful of premium feature upgrades.

Stats

1. 3 billion page views a month
2. Top 4 most trafficked mobile website after MySpace, Facebook and Google (http://www.groundtruth.com/mobile-is-mobile)
3. 75% mobile Web, 25% Web
4. 12 million members
5. 6 million unique visitors a month
6. 100k concurrent users
7. 12 million photo uploads a month
8. 2 million emails received a day, 90% spam, 2.5 million sent a day
9. Team of 8 developers, 2 QA, 1 sysadmin

Platform

1. CentOS + Red Hat
2. Resin application server — Java Servlets, JavaServer Pages, Comet
3. PostgreSQL
4. Memcached
5. ActiveMQ’s job + message queue, in Red Hat cluster for high availability
6. Squid – static content caching, tried Varnish but had stability issues
7. JQuery + Ajax
8. S3 for user photo & video storage (8 TB) and EC2 for photo processing
9. F5 BigIP load balancers – sticky sessions, gzip compression on all pages
10. Akamai CDN – 2 TB a day, 250 million requests a day
11. Monitoring – Nagios for alerts, Zabbix for trending
12. EMC SAN – high IO performance for databases by RAIDing (RAID 10) lots of disks, replacing with high performance Fusion-io solid-state flash ioDrives, much more cost effective
13. PowerMTA for mail delivery, Barracuda spam firewalls
14. Subversion source control, Hudson for continuous integration
15. FFMPEG for Mobile to Web and Web to mobile video transcoding
16. Selenium for browser test case automation
17. Web tier
    1. 5x Dell 1950, 2x dual core, 16G RAM
    2. 5x Dell 6950/R905, 4x dual core, 32G RAM
18. Database tier
    1. 2x Sun Fire X4600 M2 Server, 8x quad core, 256G RAM
    2. 2x Dell 6950, 4x dual core, 64G RAM

Architecture

1. All pages are dynamic, with user data and customizations as well as many browser and device specific optimizations. Browser and device fragmentation issues are much greater on mobile than on the Web. Many optimizations, adaptations required based on browser capabilities, limited support for CSS/JavaScript, screen size, etc. Mobile Web traffic is often served via network proxies (gateways), with poor support for Cookies, making session management and user identification a challenge.
2. A big challenge is handling the device/browser fragmentation on the mobile Web – optimizing for a huge range of device capabilities (everything from iPhones with touchscreens to 5 year old Motorola Razrs), screen sizes, lack of / inconsistent Web standards compliance, etc. We abstract out our presentation layer so we can serve pages to all mobile devices from the same code base, and maintain a large device capabilities database (containing things like screen size, supported file types, maximum allowed page sizes, etc) which is used to drive generation of our pages. The database contains capability details for hundreds of devices and mobile browser types.
3. Database is sharded based on a user key, with a master lookup table mapping users to shards. We rolled our own query and aggregation layer, allowing us to query and join data across shards, though this is not used frequently. With sharding we sacrifice some consistency, but that’s Ok as long as you’re not running a bank. We perform data consistency checks offline, in batches, with the goal being eventual consistency. Large tables are partitioned into smaller sub tables for more efficient access, reducing time tables are locked for updates as well as operational maintenance activities. Log shipping used for warm standbys.
4. A multi-tiered caching system is used, with data cached locally within the application servers as well as distributed via Memcached. When making an update we don’t just invalidate the cache and then re-populate after reading again from the database, rather we update Memcached with the new data and save another trip to the database. When updating the cache an invalidation directive is sent via the messaging queue to the local caches on each of the application servers.
5. A distributed message queue is used for distributed server communication, everything from sending messages in realtime between users to system messages such as local cache invalidation directives.
6. Dedicated server for building and traversing social graph entirely in memory, used to generate friend recommendations, etc.
7. Load balancer used for rolling deploys of new versions of the site without affecting performance/traffic.
8. Release every 2 weeks. Longer release cycles = exponential complexity, more difficult to troubleshoot and rollback. Development team responsible for deploying to and managing production systems ¿ ¿you built it, you manage it¿.
9. Kickstart used to automate server builds from bare metal. Puppet is used to configure a server to a specific personality i.e. Webserver, database server, cache server etc, as well as to push updated policies to running nodes.

Lessons Learned

1. Make your boxes sweat. Don’t be afraid of high system load as long as response times are acceptable. We pack as many as five application server instances on a single box, each running on a different port. Scale up to the high end of commodity hardware before scaling out. Can pick up used or refurbished powerful 4U boxes for cheap.
2. Understand where your bottlenecks are in each tier. Are you CPU or IO (disk, network) bound? Database is almost always IO (disk) bound. Once the database doesn’t fit in RAM you hit a wall.
3. Profile the database religiously. Obsess when it comes to optimizing the database. Scaling Web tier is cheap and easy, database tier is much harder and expensive. Know the top queries on your system, both by execution time and frequency. Track and benchmark top queries with each release, need to catch and address performance issues with the database early. We use the pgFouine log analyzer and new PostgreSQL pg_stat_statements utility for generating profiling snapshots in real-time.
4. Design to disable. Be able to configure and turn off anything you release instantly, without requiring a code change or deployment. Load and stress testing are important but nothing like testing with live, production traffic via incremental, phased rollouts.
5. Communicate synchronously only when absolutely necessary. When one component or service fails it shouldn’t bring down other parts of the system. Do everything you can in the background or as a separate thread or process, don’t make the user wait. Update the database in batches wherever possible. Any system making requests outside the network need aggressive monitoring, timeout settings, and failure handling / retries. For example, we found S3 latency and failure rates can be significant, so we queue failed calls and retry later.
6. Think about monitoring during design, not after. Every component should produce performance, health, throughput, etc data. Set up alerts when these exceed thresholds. Consolidated graphs showing metrics across all instances, rather than just per instance, are particularly helpful for identifying issues and trends at a glance and should be reviewed daily — if normal operating behavior isn’t well understood it’s impossible to identify and respond to what isn’t. We tried many monitoring systems – Cacti, Ganglia, Hyperic, Zabbix, Nagios, as well as some custom built solutions. Whichever you use the most important thing is to be comfortable with it, otherwise you won’t use it enough. It should be easy, using templates, etc to quickly monitor new boxes and services as you throw them up.
7. Distributed sessions can be a lot of overhead. Go stateless when you can, but when you can’t consider sticky sessions. If the server fails the user loses their state and may need to re-login, but that’s rare and acceptable depending on what you need to do.
8. Monitor and beware of full/major garbage collection events in Java, which can lock up the whole JVM for up to 30 seconds. We use Concurrent Mark Sweep (CMS) garbage collector, which introduces some additional system overhead, but have been able to eliminate full garbage collections.
9. When a site gets large enough it becomes a magnet for spammers and hackers, both on site and from outside via email, etc. Captcha and IP monitoring are not enough. Must invest aggressively in detection and containment systems, internal tools to detect suspicious user behavior and alert and/or attempt to automatically contain.
10. Soft delete whenever possible. Mark data for later deletion, rather than deleting immediately. Deletion can be costly, so queue up for after hours, plus if someone makes a mistake and deletes something they shouldn¿t have it¿s easy to rollback.
11. N+1 design. Never less than two of anything.

I’d really like to thank Jamie for taking the time write this experience report. It’s a really useful contribution for others to learn from. If you would like to share the architecture for your fablous system, please contact me and we’ll get started.

^^^^^^^^^^^^^^^^^^^^^^

很实际的经验分享,值得被转载下.尤其是各个平台的搭配与使用目的,很清晰明确,看来Amazon的S3应用是越来越广泛了.目前我发现的不仅仅是twitter的头像icon的存储,又加上这个MocoSpace了.

在ubuntu10.04版本里面，sun的jdk已经被排除在标准库里面，标准库的只有openJDK了

为了安装sun的jdk

先是编译个源文件

比如

sudo vim /etc/apt/sources.list.d/partner.list

然后添加

deb http://archive.canonical.com/ lucid partner

然后保存之后

sudo apt-get update

然后就

sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-jdk

基本上就可以了.只是源实在是太慢了.. 用习惯10M的源,突然变成100多k真受不了

《The Linux Command Line》由 William E. Shotts, Jr. 所著，William E. Shotts. Jr. 是著名的 LinuxCommand.org 网站的维护者，相信资深的 Linux CLI 控都不会陌生。这本《The Linux Command Linux》有 500 多页，对 Linux 命令行进行了全面的介绍，但是写得深入浅出，不仅适合 Linux CLI 新手阅读，就算是老鸟也能从中有所崭获。

本书是免费的，为 PDF 格式，可从这里下载。