特別關心源碼
① HTML5編寫的網站，網頁瀏覽能否看到源代碼
能；
操作如下：
右鍵點擊對應網頁；
選擇查看源文件；
② 現在很多瀏覽器都可以查看源碼，然後就可以查看到導入的css和js文件，怎麼可以讓用戶查看不到呢
當然可以了，
在頁面里直接這樣寫就行
<!--[if IE]><link type="text/css" rel="stylesheet" href="style_ie.css" /><![endif]-->
具體的文章如下：
條件注釋只能在windows Internet Explorer(以下簡稱IE)下使用，因此我們可以通過條件注釋來為IE添加特別的指令。
通俗點，條件注釋就是一些if判斷，但這些判斷不是在腳本里執行的，而是直接在html代碼里執行的，比如：
<!--[if IE]>
這里是正常的html代碼
<![endif]-->
1，條件注釋的基本結構和HTML的注釋(<!-- -->)是一樣的。因此IE以外的瀏覽器將會把它們看作是普通的注釋而完全忽略它們。
2，IE將會根據if條件來判斷是否如解析普通的頁面內容一樣解析條件注釋里的內容。
3，條件注釋使用的是HTML的注釋結構，因此他們只能使用在HTML文件里，而不能在CSS文件中使用。
可使用如下代碼檢測當前IE瀏覽器的版本（注意：在非IE瀏覽器中是看不到效果的）
<!--[if IE]>
<h1>您正在使用IE瀏覽器</h1>
<!--[if IE 5]>
<h2>版本 5</h2>
<![endif]-->
<!--[if IE 5.0]>
<h2>版本 5.0</h2>
<![endif]-->
<!--[if IE 5.5]>
<h2>版本 5.5</h2>
<![endif]-->
<!--[if IE 6]>
<h2>版本 6</h2>
<![endif]-->
<!--[if IE 7]>
<h2>版本 7</h2>
<![endif]-->
<![endif]-->
那如果當前的瀏覽器是IE，但版本比IE5還低，該怎麼辦呢，可以使用<!--[if ls IE 5]>，當然，根據條件注釋只能在IE5+的環境之下，所以<!--[if ls IE 5]>根本不會被執行。
lte：就是Less than or equal to的簡寫，也就是小於或等於的意思。
lt ：就是Less than的簡寫，也就是小於的意思。
gte：就是Greater than or equal to的簡寫，也就是大於或等於的意思。
gt ：就是Greater than的簡寫，也就是大於的意思。
! ：就是不等於的意思，跟javascript里的不等於判斷符相同
Conditional comments屬於CSS hack? 條件判斷屬於CSS hack嗎？
嚴格地說是屬於CSS hack。因為就好象其他真正的css hack一樣，它使得我們可以給一些瀏覽器賦予特殊的樣式，再則它不依賴於某個瀏覽器的BUG來控制另外一個瀏覽器（的樣式）。除此之外，條件判斷還能用來做一些超出CSS HACK范圍的事情(雖然這種情況很少發生)。
因為條件判斷不依賴於某個瀏覽器的hack,而是一個經過深思熟慮的特色功能，所以我相信它是可以被放心地使用的。當然，其他瀏覽器也有可能支持條件判斷（到目前為止還沒有），但是看起來，他們應該不會使用如<!--[if IE]>這樣的語法。
應該如何應用條件注釋
本文一開始就說明了，因為IE各版本的瀏覽器對我們製作的WEB標準的頁面解釋不一樣，具體就是對CSS的解釋不同，我們為了兼容這些，可運用條件注釋來各自定義，最終達到兼容的目的。比如：
<!-- 默認先調用css.css樣式表 -->
<link rel="stylesheet" type="text/css" href="css.css" />
<!--[if IE 7]>
<!-- 如果IE瀏覽器版是7,調用ie7.css樣式表 -->
<link rel="stylesheet" type="text/css" href="ie7.css" />
<![endif]-->
<!--[if lte IE 6]>
<!-- 如果IE瀏覽器版本小於等於6,調用ie.css樣式表 -->
<link rel="stylesheet" type="text/css" href="ie.css" />
<![endif]-->
這其中就區分了IE7和IE6向下的瀏覽器對CSS的執行，達到兼容的目的。同時，首行默認的css.css還能與其他非IE瀏覽器實現兼容。
注意：默認的CSS樣式應該位於HTML文檔的首行，進行條件注釋判斷的所有內容必須位於該默認樣式之後。
比如如下代碼，在IE瀏覽器下執行顯示為紅色，而在非IE瀏覽器下顯示為黑色。如果把條件注釋判斷放在首行，則不能實現。該例題很能說明網頁對IE瀏覽器和非IE瀏覽器間的兼容性問題解決。
<style type="text/css">
body{
background-color: #000;
}
</style>
<!--[if IE]>
<style type="text/css">
body{
background-color: #F00;
}
</style>
<![endif]-->
同時，有人會試圖使用<!--[if !IE]>來定義非IE瀏覽器下的狀況，但注意：條件注釋只有在IE瀏覽器下才能執行，這個代碼在非IE瀏覽下非單不是執行該條件下的定義，而是當做注釋視而不見。
正常就是默認的樣式，對IE瀏覽器需要特殊處理的，才進行條件注釋。
③ 如何搭建python環境
1、說明：windows下設置python環境變數，就是把python的安裝目錄添加到系統path中。2、步驟：1）確定python安裝目錄，根據版本不同安裝目錄也不同，可以在開始菜單中的快捷方式中查看。在python快捷方式上點右鍵，屬性菜單
3、注意事項：如果未出現python結果，則需要檢查路徑是否設置正確，並重新啟動一下計算機即可。
④ 易語言怎麼取出QQ空間顯示的特別關心
先登錄用超文本瀏覽框，用填表 取div塊源碼就可以了
⑤ 拿C來舉例:從源代碼到真正的軟體要經過什麼步驟呢
1、寫代碼，就是用c語言來實現你所要的功能
2、編譯成*.obj文件 ，由編譯器來生成*.obj文件
3、鏈接生成*.exe文件 ，同樣由編譯器生成*.exe文件
ok，就可以運行了
其實你不需要特別關心這中間的過程，因為這都是由編譯環境自動實現了。你應該主要考慮如何實現你所要的功能，以及編寫相應的軟體文檔
所謂APK指的是Android操作系統的應用程序安裝文件。所謂Crack，簡單地理解為「破解」。我具體指的是反編譯APK文件進行匯編級的代碼分析，並修改或插入自己的代碼，重新簽名打包為APK文件，以達到改變程序原有行為的目的。
由以上的說明可知，我們要Crack一個APK文件，主要流程有三步：反編譯、代碼分析、重新打包簽名。
基本准備
我們需要一些基本的工具進行一些主要的工作。如果你是一個會做Android APK漢化的朋友，那麼你應該對這些工具非常熟悉：
第一個工具是android-apktool，A tool for reengineering Android apk files 。這個工具是我們完成APK Crack的核心，利用它實現APK文件的反編譯和重新打包。它是Google Code上一個非常著名的開源項目，大家可以在Google Code的網頁上獲取它和它的Wiki、源碼及其他相關信息。
第二個工具是Auto-sign。這個工具實現的是APK打包後的簽名工作，屬於一個小工具。
除了這些基本工具外，為了更好的分析代碼，你可能還需要用到一些其他工具，例如：dex2jar和jd-gui等，這里不做詳述。
反編譯
如果你是一個經常漢化APK程序的朋友，那麼反編譯這一步你肯定不會陌生。不過，既然這篇文章側重於基本流程講解，那麼這一步想來是不能省掉的。所以，覺得羅嗦的朋友，請跳過。首先我們需要有一個待反編譯的APK。這里我自己寫了一個HelloWorld的APK，代碼如下：
package com.zh_weir.helloworld;import android.app.Activity;
import android.os.Bundle;
public class MainActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}
復制代碼
我們通過android-apktool對這個APK進行反編譯。對於android-apktool的使用，我就不做太多翻譯的工作，直接給出說明文檔吧。簡單一句話，就是命令行執行。
Apktool v1.3.2 - a tool for reengineering Android apk files
Copyright 2010 Ryszard Wi?niewski <[email protected]>
Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0)
Usage: apktool [-v|--verbose] COMMAND [...]
COMMANDs are:
d[ecode] [OPTS] <file.apk> [<dir>]
Decode <file.apk> to <dir>.
OPTS:
-s, --no-src
Do not decode sources.
-r, --no-res
Do not decode resources.
-d, --debug
Decode in debug mode. Check project page for more info.
-f, --force
Force delete destination directory.
-t <tag>, --frame-tag <tag>
Try to use framework files tagged by <tag>.
--keep-broken-res
Use if there was an error and some resources were dropped, e.g.:
"Invalid config flags detected. Dropping resources", but you
want to decode them anyway, even with errors. You will have to
fix them manually before building.
b[uild] [OPTS] [<app_path>] [<out_file>]
Build an apk from already decoded application located in <app_path>.
It will automatically detect, whether files was changed and perform
needed steps only.
If you omit <app_path> then current directory will be used.
If you omit <out_file> then <app_path>/dist/<name_of_original.apk>
will be used.
OPTS:
-f, --force-all
Skip changes detection and build all files.
-d, --debug
Build in debug mode. Check project page for more info.
if|install-framework <framework.apk>
Install framework file to your system.
For additional info, see: http://code.google.com/p/android-apktool/
復制代碼
通過apktool d HelloWorld.apk的命令，我們就完成了一個簡單的APK的反編譯工作。得到了一個叫做「HelloWorld」的文件夾。你可以看見文件夾下有Manifest文件，有反編譯出的res資源文件。這些東西都是平時漢化特別關心的，而不是我們要注意的重點。我們需要注意的是一個叫做「smali」的文件夾。
仔細觀察，你會發現這個文件夾下的文件組織結構和我們的Android工程中java源碼的組織結構幾乎一致。只不過Java文件被.smali的文件取而代之了。我們用文本編輯器打開這些.smali文件，你會發現它們都是可識別的、並且非常「整齊」的文本文件。
⑦ 如何查看spring源碼
1.准備工作：在官網上下載了Spring源代碼之後，導入Eclipse，以方便查詢。
2.打開我們使用Spring的項目工程，找到Web.xml這個網站系統配置文件，在其中找到Spring的初始化信息：
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
由配置信息可知，我們開始的入口就這里ContextLoaderListener這個監聽器。
在源代碼中我們找到了這個類，它的定義是：
public class ContextLoaderListener extends ContextLoader
implements ServletContextListener {
…
/**
* Initialize the root web application context.
*/
public void contextInitialized(ServletContextEvent event) {
this.contextLoader = createContextLoader();
if (this.contextLoader == null) {
this.contextLoader = this;
}
this.contextLoader.initWebApplicationContext(event.getServletContext());
}
...
}
該類繼續了ContextLoader並實現了監聽器，關於Spring的信息載入配置、初始化便是從這里開始了，具體其他閱讀另外寫文章來深入了解。
二、關於IOC和AOP
關於Spring IOC 網上很多相關的文章可以閱讀，那麼我們從中了解到的知識點是什麼？
1）IOC容器和AOP切面依賴注入是Spring是核心。
IOC容器為開發者管理對象之間的依賴關系提供了便利和基礎服務，其中Bean工廠（BeanFactory）和上下文（ApplicationContext）就是IOC的表現形式。BeanFactory是個介面類，只是對容器提供的最基本服務提供了定義，而DefaultListTableBeanFactory、XmlBeanFactory、ApplicationContext等都是具體的實現。
介面：
public interface BeanFactory {
//這里是對工廠Bean的轉義定義，因為如果使用bean的名字檢索IOC容器得到的對象是工廠Bean生成的對象，
//如果需要得到工廠Bean本身，需要使用轉義的名字來向IOC容器檢索
String FACTORY_BEAN_PREFIX = "&";
//這里根據bean的名字，在IOC容器中得到bean實例，這個IOC容器就象一個大的抽象工廠，用戶可以根據名字得到需要的bean
//在Spring中，Bean和普通的JAVA對象不同在於：
//Bean已經包含了我們在Bean定義信息中的依賴關系的處理，同時Bean是已經被放到IOC容器中進行管理了，有它自己的生命周期
Object getBean(String name) throws BeansException;
//這里根據bean的名字和Class類型來得到bean實例，和上面的方法不同在於它會拋出異常：如果根名字取得的bean實例的Class類型和需要的不同的話。
Object getBean(String name, Class requiredType) throws BeansException;
//這里提供對bean的檢索，看看是否在IOC容器有這個名字的bean
boolean containsBean(String name);
//這里根據bean名字得到bean實例，並同時判斷這個bean是不是單件，在配置的時候，默認的Bean被配置成單件形式,如果不需要單件形式，需要用戶在Bean定義信息中標注出來，這樣IOC容器在每次接受到用戶的getBean要求的時候，會生成一個新的Bean返回給客戶使用 - 這就是Prototype形式
boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
//這里對得到bean實例的Class類型
Class getType(String name) throws NoSuchBeanDefinitionException;
//這里得到bean的別名，如果根據別名檢索，那麼其原名也會被檢索出來
String[] getAliases(String name);
}
實現：
XmlBeanFactory的實現是這樣的：
public class XmlBeanFactory extends DefaultListableBeanFactory {
//這里為容器定義了一個默認使用的bean定義讀取器，在Spring的使用中，Bean定義信息的讀取是容器初始化的一部分，但是在實現上是和容器的注冊以及依賴的注入是分開的，這樣可以使用靈活的 bean定義讀取機制。
private final XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(this);
//這里需要一個Resource類型的Bean定義信息，實際上的定位過程是由Resource的構建過程來完成的。
public XmlBeanFactory(Resource resource) throws BeansException {
this(resource, null);
}
//在初始化函數中使用讀取器來對資源進行讀取，得到bean定義信息。這里完成整個IOC容器對Bean定義信息的載入和注冊過程
public XmlBeanFactory(Resource resource, BeanFactory parentBeanFactory) throws
BeansException {
super(parentBeanFactory);
this.reader.loadBeanDefinitions(resource);
}
⑧ HBase 寫性能優化
上一篇文章主要介紹了HBase讀性能優化的基本套路，本篇文章來說道說道如何診斷HBase寫數據的異常問題以及優化寫性能。和讀相比，HBase寫數據流程倒是顯得很簡單：數據先順序寫入HLog，再寫入對應的緩存Memstore，當Memstore中數據大小達到一定閾值（128M）之後，系統會非同步將Memstore中數據flush到HDFS形成小文件。
HBase數據寫入通常會遇到兩類問題，一類是寫性能較差，另一類是數據根本寫不進去。這兩類問題的切入點也不盡相同，如下圖所示：
優化原理：數據寫入流程可以理解為一次順序寫WAL+一次寫緩存，通常情況下寫緩存延遲很低，因此提升寫性能就只能從WAL入手。WAL機制一方面是為了確保數據即使寫入緩存丟失也可以恢復，另一方面是為了集群之間非同步復制。默認WAL機制開啟且使用同步機制寫入WAL。首先考慮業務是否需要寫WAL，通常情況下大多數業務都會開啟WAL機制（默認），但是對於部分業務可能並不特別關心異常情況下部分數據的丟失，而更關心數據寫入吞吐量，比如某些推薦業務，這類業務即使丟失一部分用戶行為數據可能對推薦結果並不構成很大影響，但是對於寫入吞吐量要求很高，不能造成數據隊列阻塞。這種場景下可以考慮關閉WAL寫入，寫入吞吐量可以提升2x~3x。退而求其次，有些業務不能接受不寫WAL，但可以接受WAL非同步寫入，也是可以考慮優化的，通常也會帶來1x～2x的性能提升。
優化推薦：根據業務關注點在WAL機制與寫入吞吐量之間做出選擇
其他注意點：對於使用Increment操作的業務，WAL可以設置關閉，也可以設置非同步寫入，方法同Put類似。相信大多數Increment操作業務對WAL可能都不是那麼敏感～
優化原理：HBase分別提供了單條put以及批量put的API介面，使用批量put介面可以減少客戶端到RegionServer之間的RPC連接數，提高寫入性能。另外需要注意的是，批量put請求要麼全部成功返回，要麼拋出異常。
優化建議：使用批量put進行寫入請求
優化原理：業務如果可以接受異常情況下少量數據丟失的話，還可以使用非同步批量提交的方式提交請求。提交分為兩階段執行：用戶提交寫請求之後，數據會寫入客戶端緩存，並返回用戶寫入成功；當客戶端緩存達到閾值（默認2M）之後批量提交給RegionServer。需要注意的是，在某些情況下客戶端異常的情況下緩存數據有可能丟失。
優化建議：在業務可以接受的情況下開啟非同步批量提交
使用方式：setAutoFlush(false)
優化原理：當前集群中表的Region個數如果小於RegionServer個數，即Num(Region of Table) < Num(RegionServer)，可以考慮切分Region並盡可能分布到不同RegionServer來提高系統請求並發度，如果Num(Region of Table) > Num(RegionServer)，再增加Region個數效果並不明顯。
優化建議：在Num(Region of Table) < Num(RegionServer)的場景下切分部分請求負載高的Region並遷移到其他RegionServer；
優化原理：另一個需要考慮的問題是寫入請求是否均衡，如果不均衡，一方面會導致系統並發度較低，另一方面也有可能造成部分節點負載很高，進而影響其他業務。分布式系統中特別害怕一個節點負載很高的情況，一個節點負載很高可能會拖慢整個集群，這是因為很多業務會使用Mutli批量提交讀寫請求，一旦其中一部分請求落到該節點無法得到及時響應，就會導致整個批量請求超時。因此不怕節點宕掉，就怕節點奄奄一息！
優化建議：檢查RowKey設計以及預分區策略，保證寫入請求均衡。
KeyValue大小對寫入性能的影響巨大，一旦遇到寫入性能比較差的情況，需要考慮是否由於寫入KeyValue數據太大導致。KeyValue大小對寫入性能影響曲線圖如下：
圖中橫坐標是寫入的一行數據（每行數據10列）大小，左縱坐標是寫入吞吐量，右坐標是寫入平均延遲（ms）。可以看出隨著單行數據大小不斷變大，寫入吞吐量急劇下降，寫入延遲在100K之後急劇增大。
說到這里，有必要和大家分享兩起在生產線環境因為業務KeyValue較大導致的嚴重問題，一起是因為大欄位業務寫入導致其他業務吞吐量急劇下降，另一起是因為大欄位業務scan導致RegionServer宕機。
案件一：大欄位寫入導致其他業務吞吐量急劇下降
部分業務反饋集群寫入忽然變慢、數據開始堆積的情況，查看集群表級別的數據讀寫QPS監控，發現問題的第一個關鍵點：業務A開始寫入之後整個集群其他部分業務寫入QPS都幾乎斷崖式下跌，初步懷疑黑手就是業務A。
下圖是當時業務A的寫入QPS（事後發現腦殘忘了截取其他表QPS斷崖式下跌的慘象），但是第一感覺是QPS並不高啊，憑什麼去影響別人！
於是就繼續查看其他監控信息，首先確認系統資源（主要是IO）並沒有到達瓶頸，其次確認了寫入的均衡性，直至看到下圖，才追蹤到影響其他業務寫入的第二個關鍵點：RegionServer的handler（配置150）被殘暴耗盡：
對比上面兩張圖，是不是發現出奇的一致，那就可以基本確認是由於該業務寫入導致這台RegionServer的handler被耗盡，進而其他業務拿不到handler，自然寫不進去。那問題來了，為什麼會這樣？正常情況下handler在處理完客戶端請求之後會立馬釋放，唯一的解釋是這些請求的延遲實在太大。
試想，我們去漢堡店排隊買漢堡，有150個窗口服務，正常情況下大家買一個很快，這樣150個窗口可能只需要50個服務。假設忽然來了一批大漢，要定製超大漢堡，好了，所有的窗口都工作起來，而且因為大漢堡不好製作導致服務很慢，這樣必然會導致其他排隊的用戶長時間等待，直至超時。
可回頭一想這可是寫請求啊，怎麼會有這么大的請求延遲！和業務方溝通之後確認該表主要存儲語料庫文檔信息，都是平均100K左右的數據，是不是已經猜到了結果，沒錯，就是因為這個業務KeyValue太大導致。KeyValue太大會導致HLog文件寫入頻繁切換、flush以及compaction頻繁觸發，寫入性能急劇下降。
目前針對這種較大KeyValue寫入性能較差的問題還沒有直接的解決方案，好在社區已經意識到這個問題，在接下來即將發布的下一個大版本HBase 2.0.0版本會針對該問題進行深入優化，詳見 HBase MOB ，優化後用戶使用HBase存儲文檔、圖片等二進制數據都會有極佳的性能體驗。
案件二：大欄位scan導致RegionServer宕機
案件現場：有段時間有個0.98集群的RegionServer經常頻繁宕機，查看日誌是由於」java.lang.OutOfMemoryError: Requested array size exceeds VM limit」，如下圖所示：
原因分析：通過查看源碼以及相關文檔，確認該異常發生在scan結果數據回傳給客戶端時由於數據量太大導致申請的array大小超過JVM規定的最大值（ Interge.Max_Value-2）。造成該異常的兩種最常見原因分別是：
有的童鞋就要提問啦，說如果已經對返回結果大小做了限制，在表列太寬的情況下是不是就可以不對列數量做限制呢。這里需要澄清一下，如果不對列數據做限制，數據總是一行一行返回的，即使一行數據大小大於設置的返回結果限制大小，也會返回完整的一行數據。在這種情況下，如果這一行數據已經超過array大小閾值，也會觸發OOM異常。
解決方案：目前針對該異常有兩種解決方案，其一是升級集群到1.0，問題都解決了。其二是要求客戶端訪問的時候對返回結果大小做限制(scan.setMaxResultSize(2 1024 1024))、並且對列數量做限制(scan.setBatch(100))，當然，0.98.13版本以後也可以對返回結果大小在伺服器端進行限制，設置參數hbase.server.scanner.max.result.size即可
上述幾點主要針對寫性能優化進行了介紹，除此之外，在一些情況下還會出現寫異常，一旦發生需要考慮下面兩種情況（GC引起的不做介紹）：
問題解析：以RegionServer級別flush進行解析，HBase設定一旦整個RegionServer上所有Memstore佔用內存大小總和大於配置文件中upperlimit時，系統就會執行RegionServer級別flush，flush演算法會首先按照Region大小進行排序，再按照該順序依次進行flush，直至總Memstore大小低至lowerlimit。這種flush通常會block較長時間，在日誌中會發現「Memstore is above high water mark and block 7452 ms」，表示這次flush將會阻塞7s左右。
問題檢查點：
問題解析：對於數據寫入很快的集群，還需要特別關注一個參數：hbase.hstore.blockingStoreFiles，此參數表示如果當前hstore中文件數大於該值，系統將會強制執行compaction操作進行文件合並，合並的過程會阻塞整個hstore的寫入。通常情況下該場景發生在數據寫入很快的情況下，在日誌中可以發現」Waited 3722ms on a compaction to clean up 『too many store files「
問題檢查點：
上文已經從寫性能優化以及寫異常診斷兩個方面對HBase中數據寫入可能的問題進行了詳細的解釋，相信在0.98版本的基礎上對寫入來說已經是最好的解決方案了。但是有些業務可能依然覺得不夠快，畢竟」更快」是所有存儲系統活著的動力，那還有提高空間嗎？當然，接下來簡單介紹HBase之後版本對寫性能優化的兩點核心改進：
這個特性意味著可以將WAL單獨置於SSD上，這樣即使在默認情況下（WALSync），寫性能也會有很大的提升。需要注意的是，該特性建立在HDFS 2.6.0+的基礎上，HDFS以前版本不支持該特性。具體可以參考官方jira： https://issues.apache.org/jira/browse/HBASE-12848
該特性也是對WAL進行改造，當前WAL設計為一個RegionServer上所有Region共享一個WAL，可以想像在寫入吞吐量較高的時候必然存在資源競爭，降低整體性能。針對這個問題，社區小夥伴（阿里巴巴大神）提出Multiple WALs機制，管理員可以為每個Namespace下的所有表設置一個共享WAL，通過這種方式，寫性能大約可以提升20%～40%左右。具體可以參考官方jira： https://issues.apache.org/jira/browse/HBASE-14457
⑨ c語言編寫。計算1+1/（1+2）+1/（1+2+3）+.....+1/（ 1+2+3+.....
#include<stdio.h>
main()
{
int n,i,j,sum=0;
printf("請你輸入n的值：");
scanf("%d",&n);//由鍵盤輸入n的值
for(i=n;i>0;i--)//控制數列項數
{
for(j=1;j<=n-i+1;j++)//控制每一個項包含的數字的數量
sum+=j;//計算前n項的和
}
printf("1+1/(1+2)+...+(1+2+...+%d))=%d",n,sum);
}
(9)特別關心源碼擴展閱讀：
include用法：
#include命令預處理命令的一種，預處理命令可以將別的源代碼內容插入到所指定的位置；可以標識出只有在特定條件下才會被編譯的某一段程序代碼；可以定義類似標識符功能的宏，在編譯時，預處理器會用別的文本取代該宏。
插入頭文件的內容
#include命令告訴預處理器將指定頭文件的內容插入到預處理器命令的相應位置。有兩種方式可以指定插入頭文件：
1、#include<文件名>
2、#include"文件名"
⑩ golang 多人開發怎麼保證源碼安全
隨著PHP有著越來越深入的了解，以及遇到越來越多的不同業務時，使用PHP總會讓我有一種莫名的無力感。當然，並不是我一個人在使用PHP的時候遇到了問題。事實上，每個略微有一些經驗，接觸過一些需求的人都會有同樣的困惑。各種配合LAMP（或者LNMP？）架構的後端技術也因此被發明或被發現，進而整合到PHP的開發的技術體系中。從簡單的Memcached作為數據中轉，cron後端定時處理；到Gearman、RabbitMQ這些隊列神器；最近Laruence甚至封裝了利用libcurl的非同步特性實現並發RPC調用的yar擴展。幾乎整個社區都在尋找PHP的摩西之路。好吧，說了一大堆，回歸主題。之前我寫了一篇英文練筆《》，獲得不少國際友人的關注。排除拼寫和語法被他們詬病外，主要是有許多朋友覺得我沒把事情說清楚。所以這里我用母語重新聊聊這個事情，只是這些國際友人什麼時候能學會閱讀中文呢？；）Go或者Golang，是由Google支持的快速、一致、穩定的，有活躍的社區支持的開源編程語言。越來越多的應用選擇使用Golang進行構建。雖然RobPike說「…我們希望C++程序員來了解Go並作為一個可選的語言…」，不過我真得認為：PHPer應當學習Golang！接下來我們就來談談原因。容易學習PHP相當容易學習。Golang也是！在這點上，一群大老外對我的觀點進行了猛烈的抨擊。他們認為我羞辱了PHPer，說得好像只有簡單的東西PHPer才能學會一樣。但是，這難道不是事實嗎？或者換個說法：像我一樣的喜歡PHP的人，或多或少都會更喜歡簡單的東西。PHP的語法接近C族編程語言（C/C++/Java等等）。如果有這些語言的經驗，在第一次遇到PHP的時候立刻就能開始上手編寫代碼。在我看來，編寫PHP代碼或許更加考驗程序員的記憶力，而不是智力（當你面對各種不同風格的函數定義、各種擴展的特殊約定時，你一定會相當認同我的觀點）。Golang同樣是一個C族編程語言。呃，或者有一些不同吧。例如關鍵字「for」，功能上和PHP的接近，但是沒有括弧。條件語句「if」同樣無需括弧。可以閱讀EffectiveGo了解內容。Golang只有3025個關鍵字和47個操作符號、分隔符號或其他特殊標記。記住這些標記確實不需要什麼特別的努力。精巧的類型系統相當容易使用。實用的，具有方法的結構體類型代替了笨重的對象系統。介面的設計是Golang中我最喜歡的部分。當完成了《Go指南》的學習之後，利用PHP積累的經驗，立刻就可以開始使用Golang處理一些簡單的任務。容易使用PHP腳本是由SAPI組件進行解析執行的，如Web伺服器模塊、PHP-FPM或者CLI。部署PHP所需要的全部東西就是一個SAPI環境。配置這個環境對於新手來說可能是學習PHP過程中最為困難的部分。所有的Golang代碼會編譯和鏈接為本地碼。所以除了編譯環境，執行時無需再為其進行任何特別的部署。對比PHP環境的配置，這要簡單很多。你真得認為配置PHP環境很復雜嗎？我不覺得，真的！而配置Golang編譯環境比那還要簡單點。我確信已經有大量的Golang相關的書籍、文章介紹過如何進行編譯環境的配置了。為了更加清晰，我這里梳理一下思路。有三個步驟需要處理：下載Golang的源代碼；根據《[翻譯]Go環境設置》的提示設置環境變數；運行源代碼src目錄中的all.bash。或者一步到位：使用二進制包進行安裝。然後就會得到一個叫做「go」的工具集合。使用「go」工具和使用PHP的CLI工具一樣簡單。《[翻譯]go工具》對此進行了詳細的解釋。PHP的迷思如果一個編程語言容易學習和使用，我們是不是就應當學習它呢？有許多容易學習和使用的編程語言。難道要把它們都學一遍？答案是顯然的：NO!但是呢？只是因為它很酷！是的，我在開玩笑，但是這是真的。無論如何先從PHP自身談起吧。PHP「原本是為了開發動態的Web頁面而設計的伺服器端通用語言(Wikipedia)」。PHP一個重要的特性就是可以嵌入到HMTL中。代碼編寫在「」標簽內；HTML寫在標簽外。它有一個強大的擴展系統。擴展使用C調用ZendAPI編寫。數據的處理實際上要利用這些擴展完成。在我看來，PHP是世界上最好的模板語言。但是當積累了一些PHP的經驗，並且開始面對一些更加復雜的Web應用時，你一定會對PHP產生一種無力的感覺。它沒有內建的並行機制，沒有線程、進程（你真得認為那個簡陋的進程式控制制可以不加改造的用在高並發的生產環境？），或者其他某「程」。一個慢數據源可以阻塞整個頁面的處理。消息隊列、緩存、代理……系統開始不僅僅是PHP這么單純，還包括了許多服務和系統組件。這時，PHP只處理很少的業務邏輯，成為真正的模板語言了。PHPer們總是在尋找解決這一問題的法，如「PHPmultithread」或者PHPRPC並發框架。我很難說哪種會更好一些。不過我肯定你會需要選擇一些編程語言用於後端工作的開發。就我自己的經驗，我嘗試過C（一直在和malloc/free進行搏鬥）/Java（陷入到了jar地獄中）/Python（從來沒能做到Pythonic不說，還總是在錯誤的類型中打轉）……如果想要獲得性能，就得同內存管理進行搏鬥；如果用GC，就得部署和調優VM；當獲得便利性的時候，同時也是走在刀尖上，一個小錯誤就引起巨大的災難……每個都有優勢，同樣每個都有問題。好吧！現在回到Golang！Golang有GC，無需關心內存管理（或者可以用較少的精力去關注它）。代碼被編譯為本地碼，因此「cp」和「mv」就是部署Golang編寫的應用所需要的全部工具。噢，我剛才已經說過了，Golang是一個具有靜態類型系統的編譯語言。所以你沒有機會弄亂變數的類型。當然，PHPer應該學習Golang的一個重要原因是「轉到Go是因為他們並未放棄太多的表達能力，但是獲得了性能，並且與並發共舞（RobPike）」。《WhyNotGo?（英文）》對此進行了深入的分析。我可以分享一些我的經驗：有一個Gearman的worker用於處理後端數據。PHP通過其API連接到Gearman的JobServer向worker發起請求。最初worker是使用python編寫的（還有更加原始的版本，PHP的，但是你能想像它工作起來……唉，不說了……）。這個版本有許多的問題（是我們自己的問題，不關Python的事），但是至少它能工作。後來用Golang重寫了這個worker。為此我開發了Golang的GearmanAPI，並使用ZendAPI編寫了一個在Golang中執行PHP腳本的包。然後將它們放在一起：一個可以執行PHP的Gearmanworker。它已經工作了一段時間了，看起來還不錯！哦，受到Yar的啟發，這里還有一個Golang編寫的RPC合並器，用來合並PHP腳本中的RPC調用。現在還是個玩具，不過或許日後能用得著。這其實是將Golang的channel當作消息隊列來用。我在《Golang：有趣的channel應用》中對此有一些說明。世界真美好啊。謝謝Golang！無論如何，大多數PHPer在進行後端開發的時候都會需要學習一些其他語言。如果你正在尋找，或者已經嘗試了一些其他語言。為什麼不來試試Golang？它真得可以讓你的生活更加輕松和快樂。讓你可以有的時間陪伴你的家人和朋友，吃你愛吃的東西，去你想去的地方。貌似我還是沒說清楚啊？好吧，沒關系，在下個月的中國軟體開發者大會上再跟大家就這個話題做一個探討吧。