6月17日至6月19日，由挪威工程機械協(xié)會主辦的豪格森建筑機械展在美麗的挪威城市豪格森拉開序幕。
本次參展商涵蓋了卡特、沃爾沃、小松、日立、斗山、現(xiàn)代等國際知名企業(yè)，其專業(yè)程度可見一斑。三一重機攜小挖產(chǎn)品SY75C和SY135C亮相該展會，為登陸挪威市場打下基礎。
展覽期間，有近千人來到了三一展位參觀、咨詢，并有超過200位客戶到室外試驗場親自操作三一挖掘機。參加試駕客戶之多，一度讓主辦方專門為三一試駕場地拉起了安全線。參與試駕的客戶普遍對三一小挖產(chǎn)品給予了極大的肯定。更有客戶在展會現(xiàn)場就做出了購買SY75C的決定。
據(jù)悉，三一重機國際營銷本部多次組織人員對當?shù)?0噸以下的挖機產(chǎn)品進行市場調(diào)研，撰寫調(diào)研報告，并與小挖研究院、國際車間一起研究制定符合當?shù)厥袌龅奶厥馀渲茫瑸槿恍⊥诋a(chǎn)品在歐洲市場的銷售打下了牢固的基礎。
中國鋼鐵工業(yè)協(xié)會2日公布，上半年鋼鐵生產(chǎn)平穩(wěn)但增速有所回落，全國粗鋼產(chǎn)量3.50億噸，同比增長9.6%，依此計算全年粗鋼產(chǎn)量將達
7.06億噸。但由于鋼材出口自3月份始呈逐月下降趨勢，下半年除建筑鋼材需求增長顯著外，生產(chǎn)用板帶材市場難有起色，預測下半年鋼
鐵產(chǎn)量增速將可能放緩。
中鋼協(xié)認為，下半年汽車零部件用鋼材市場需求將較旺盛，因為保障性住房大規(guī)模開工建設以及大規(guī)模水利工程建設也將陸續(xù)開展。但造
船、汽車、工程機械等增長趨緩，鋼材產(chǎn)品結構性矛盾會更加突出，板帶材產(chǎn)能過剩和產(chǎn)品的同質(zhì)化競爭將更加激烈。
中鋼協(xié)認為，下半年全行業(yè)將面臨更大的資金壓力和經(jīng)營困難。上半年進口鐵礦石大幅上漲，致使企業(yè)生產(chǎn)經(jīng)營困難，中鋼協(xié)會員
企業(yè)上半年銷售利潤率僅為3.14%，同比下降0.4個百分點。上半年鐵礦石平均到岸價格同比上漲42.41%至每噸160.89美元，創(chuàng)歷史最高
水平，同時煤炭、電力價格上漲，使得鋼鐵企業(yè)生產(chǎn)高成本短期內(nèi)難以改變。預計下半年貨幣政策進一步趨緊，企業(yè)面臨的形勢將更加嚴峻。
我們在編寫代碼的時候，會出現(xiàn)一些的小的錯誤。下面介紹的是對于java中經(jīng)常出現(xiàn)的一些錯誤的總結(中國兵器工程機械集團——Mr.Z)。
代碼審查是消滅Bug最重要的方法之一，這些審查在大多數(shù)時候都特別奏效。由于代碼審查本身所針對的對象，就是俯瞰整個代碼在測試過程中的問題和 Bug。并且，代碼審查對消除一些特別細節(jié)的錯誤大有裨益，尤其是那些能夠容易在閱讀代碼的時候發(fā)現(xiàn)的錯誤，這些錯誤往往不容易通過機器上的測試識別出來。本文就常見的Java代碼中容易出現(xiàn)的問題提出一些建設性建議，以便您在審查代碼的過程中注意到這些常見的細節(jié)性錯誤。
通常給別人的工作挑錯要比找自己的錯容易些。別樣視角的存在也解釋了為什么作者需要編輯，而運動員需要教練的原因。不僅不應當拒絕別人的批評，我們應該歡迎別人來發(fā)現(xiàn)并指出我們的編程工作中的不足之處，我們會受益匪淺的。 正規(guī)的代碼審查(code inspection)是提高代碼質(zhì)量的最強大的技術之一，代碼審查—由同事們尋找代碼中的錯誤—所發(fā)現(xiàn)的錯誤與在測試中所發(fā)現(xiàn)的錯誤不同，因此兩者的關系是互補的，而非競爭的。
如果審查者能夠有意識地尋找特定的錯誤，而不是靠漫無目的的瀏覽代碼來發(fā)現(xiàn)錯誤，那么代碼審查的效果會事半功倍。在這篇文章中，我列出了11個 Java編程中常見的錯誤。你可以把這些錯誤添加到你的代碼審查的檢查列表(checklist)中，這樣在經(jīng)過代碼審查后，你可以確信你的代碼中不再存在這類錯誤了。
一、常見錯誤1# ：多次拷貝字符串
測試所不能發(fā)現(xiàn)的一個錯誤是生成不可變(immutable)對象的多份拷貝。不可變對象是不可改變的，因此不需要拷貝它。最常用的不可變對象是String。
如果你必須改變一個String對象的內(nèi)容，你應該使用StringBuffer。下面的代碼會正常工作：
String s = new String ("Text here");
但是，這段代碼性能差，而且沒有必要這么復雜。你還可以用以下的方式來重寫上面的代碼：
String temp = "Text here"; String s = new String (temp);
但是這段代碼包含額外的String，并非完全必要。更好的代碼為：
String s = "Text here";
二、常見錯誤2#： 沒有克隆(clone)返回的對象
封裝(encapsulation)是面向對象編程的重要概念。不幸的是，Java為不小心打破封裝提供了方便——Java允許返回私有數(shù)據(jù)的引用(reference)。下面的代碼揭示了這一點：
import java.awt.Dimension; /***Example class.The x and y values should never*be negative.*/ public class Example{ private Dimension d = new Dimension (0, 0); public Example (){ } /*** Set height and width. Both height and width must be nonnegative * or an exception is thrown.*/ public synchronized void setValues (int height,int width) throws IllegalArgumentException{ if (height < 0 || width < 0) throw new IllegalArgumentException(); d.height = height; d.width = width; } public synchronized Dimension getValues(){ // Ooops! Breaks encapsulation return d; } }
Example類保證了它所存儲的height和width值永遠非負數(shù)，試圖使用setValues()方法來設置負值會觸發(fā)異常。不幸的是，由于getValues()返回d的引用，而不是d的拷貝，你可以編寫如下的破壞性代碼：
Example ex = new Example(); Dimension d = ex.getValues(); d.height = -5; d.width = -10;
現(xiàn)在，Example對象擁有負值了!如果getValues() 的調(diào)用者永遠也不設置返回的Dimension對象的width 和height值，那么僅憑測試是不可能檢測到這類的錯誤。
不幸的是，隨著時間的推移，客戶代碼可能會改變返回的Dimension對象的值，這個時候，追尋錯誤的根源是件枯燥且費時的事情，尤其是在多線程環(huán)境中。