2014年10月14日 星期二

Day 1 台灣桃園機場>日本成田機場>台場日航飯店>池袋

      我們當天抵達日本的時間大約是日本時間11:30,下飛機出關後就前往機場購

買利木津巴士,其實還蠻好找的,出關領完行李後出來就可以看到了!!我們是在

日本的第二航廈,購買利木津巴士票卷的溝通上沒太大困難,因為我直接拿飯店

名稱給他看,他看一下就懂了。由成田機場到日航飯店票價原本是2800日元,我

們使用JCB信用卡打八折,所以是2240日元/人。最近也有推出利木津巴士搭配

東京地鐵的優惠票卷,大家可以先做功課找看看。買好票後,櫃檯人員會拿出地

圖告訴你哪裡可以搭車,很好找,不用擔心找不到。

 成田機場有很多穿著藍色背心的志工,英文都非常的好,有問題可以去問他們,

他們會大力的協助的。買完利木津巴士後,接著我們到樓下地鐵站附近要購買西

瓜卡,正確位子在,下手扶梯後穿越諮詢台,諮詢台的右方有個紅色的門進去右

邊,小小的不起眼(不負責任表示,應該是這樣,可以問一下)。西瓜卡一張是2000日

幣,內含500日元的押金,所以拿到第一次逼就是1500日元囉。

 我們搭上下午一點半巴士後,大約三點到飯店,路程大約90分鐘,其實後面

大概有20分鐘都是再繞台場附近的各大飯店。Check in 完我們收拾東西就準備

出門到池袋看祭典。



2014年10月4日 星期六

東京自由行-前提概要

第一次自由行就獻給了回味無窮的東京!!

我不是達人,單純分享一下這次旅遊經驗,提供給大家參考!!




        首先,先跟大家分享幾個,達人級的部落格跟這次常用的網站及app,大家可以去逛逛,裡面有很多的資料,包山包海的。不過一拜G大神,大概就會出現了這些!!!


樂活的大方@旅行玩樂學~』 連結部分直接幫大家連到東京懶人包了 XD


林氏壁和美狐團三狐的小天地』 這對於交通部分介紹的非常詳細,可以好好拜讀一下。


Go Tokyo』 這是日本旅遊官方網站中文版,裡面有東京景點跟地圖資料,不過對於一些比較即時的資訊就會比較少,還是要去日文版的稍微看一下,舉例一下,像我們第一天去池袋的祭典,中文官網就都沒看到介紹,日文才有。



接下來是app的部分,這是用安卓系統下載的!!


『日本旅遊東京活動』  這也是日本官方出的,很適合睡前看一下。


『東京地鐵乘車』  這是日本地鐵的搭車指南(未含山手線),會告訴你哪裡要換車、行駛時間跟價錢的部分,不過我從頭到尾都沒開過,因為實戰經驗我是用東京地鐵大地圖,下面會po給大家看。


『Currency』 這個是簡易換算日幣價錢的,不過我帶了個人體計算機,所以沒用到。


『翻譯』 這就是簡單的google翻譯,實戰經驗成功率大概65%,哈哈!!


『TDR排隊時間』 我只能說這個,超!!級!!好!!用!!這是可以看到迪士尼所有設施的排隊時間,海洋跟樂園部分都有。


附上我手機截圖的圖片給大家看一下。


2014年6月9日 星期一

Spring data jpa + hibernate + SpringMVC + MySQL 實現 CRUD

關於eclipse對於maven的介紹http://d12e493.blogspot.tw/search/label/Maven

關於SpringMVC的介紹http://d12e493.blogspot.tw/search/label/SpringMVC

此篇使用SpringMVC的架構

dao層則是spring data jpa及hibernate


簡單操作一個CRUD的例子,

專案建置如下:























2014年6月8日 星期日

Spring data jpa + Hibernate

利用spring data及使用jpa規範,

大量簡化了dao接口的coding,

另外還可以使用spring data的許多介面幫忙實現實作,

也不需要撰寫一般常用的CRUD以及查詢實作,

只要撰寫介面後,spring data便會幫你完成實作的部分。

2014年4月2日 星期三

Clean Code - Class

類別的首要準則為簡短,

再來根據Java的慣例,

一開始通常是宣告公用靜態變數,

再來是私有靜態變數,

然後是私有實體變數,

接著為公用函式,

緊接私有函式,

盡量讓公用函式裡會呼叫到的私有函式,

2014年4月1日 星期二

Spring Bean Annotation

在spring3.0之後使用註解配置變得相當方便,

XML的配置方式將bean和配置拆開成兩個檔案,

但使用宣告可以將配置和bean放在同一個檔案裡,

更清楚表示相關的配置訊息,

Spring Bean Scopes

在spring的配置文件中,

除了對bean作屬性和依賴關係的配置外,

另一個部分便是作用範圍的設定,

下面列出五個可以選擇的範圍 ( Spring 2.0之後 ):

2014年3月28日 星期五

Spring 3.1.2 & quartz 1.8.6 example

project中常會有需要利用排程的工作,

這邊介紹spring和quartz的整合,

首先先利用mvaen建立,可參閱maven build project

接下來是需要用到的dependencies,

2014年3月26日 星期三

SpringMVC 幾種返回形式(ModelAndView,@ModelAttribute,Model,@SessionAttribute)

在透過@RequestMapping,

將request導入到@Controller內的function後,

function運作完畢後有幾種返回的形式可以選擇:

1.ModelAndView

當返回為ModelAndView時,

其中已經包含了顯示(View)和模型(Model),

2014年3月23日 星期日

Clean Code - Note

在程式中下註解是很常見的,

但在看完clean code後,

我開始思考註解的適當性及必要性,

有些書中提到的要點可以分享一下:

1.用code代替註解

書中有提到一個重要的觀念,

不要用註解拯救糟糕的code,

寧可重新改寫code,
 //to check the member's level is enough
 if(member.level <= office_premium && member.level > office_higher){
  
 }
 
 if(member.hasEnoughLevel()){
  
 }

第一個敘述看了註解之後,

或者你可以了解if中的判斷,

但採用第二種方式之後,

你便可以繼續往下閱讀並了解此段程式碼要做什麼事情。

2.不要留註解的程式碼

以前的code中很常看到這樣的方式,

有時候是為了測試,

有時候是流程或業務內容改變,

但也怕會忘記以前的寫法所以用註解的方式保存,

但現在都有版控的機制,

可以清楚記錄每次的改版,

所以,把註解的程式碼刪除,

避免久了造成不必要的誤會。

Clean Code - function

不論是維護或者是開發時,

常常會遇到幾十、幾百甚至是幾千行的function,

當然再一邊抱怨的同時,

也同時告誡自己不要創造出如此的怪物,

在clean code中有提到一些寫function的建議:

1.只做一件事

每一個function應該只有一個目標,

只要完成一個工作,

例如if、else、while,

也應該只包含一行呼叫function的敘述,

當把握這個原則後,

你的function內也不會有幾百幾千行的code。

2.使用具描述能力的名稱

如同命名原則一樣,

countOfItem()的function應該會比count()這樣的名稱容易理解,

在思考function名稱時,

以能讓別人一眼看到就知道其含意為原則。

3.不要傳遞旗標參數

不要讓你的function接收true/false這樣的參數,

除了代表你的function做了不只一件事外,

也會影響命名function的難度。

4.以物件傳遞代替一串參數

function接收的參數盡量越少越好,

如果需要傳遞一整串的參數(2、3個以上),

可以使用物件來封裝傳遞。

5.使用try/catch代替錯誤代碼

避免使用錯誤處理代碼如error_code_1,

利用try/catch/finally來代替error_code,

就能將錯誤處理代碼的敘述抽出來並簡化,

且try/catch/finally裡面也應該只處理一件事。

2014年3月22日 星期六

SpringMVC RequestParam、CookieValue、RequestHeader

@RequestParam

在呼叫@Controller內的@RequestMapping時,

我們可以在function的地方加入RequestParam綁定對應的參數名稱,
package com.springmvc.controller;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;

@Controller
@RequestMapping("/param")
public class ParamTestController {

 @RequestMapping("/test")
 public String test(
   @RequestParam(value = "par1", defaultValue = "df") String par1,
   @RequestParam(value = "par2", required = false) int par2) {
  return "/param/test";
 }
}

@RequestParam中有三個參數可以設定,

SpringMVC PathVariable

在@RequestMapping中,

當使用URL對應時還可以使用{}占位符號的方式傳遞參數,
package com.springmvc.controller;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;

@Controller
@RequestMapping("/item")
public class ItemController {

 @RequestMapping("/{itemNo}")
 public String create(@PathVariable("itemNo") String itemNo) {
  return "/item/create";
 }

}

在ItemController中,

當您呼叫/webapp/item/123456時,

會執行create()並且幫你把123456綁定到itemNo的變數中,

除了可以使用function的占位符外,

也可以使用class的占位符,

SpringMVC Request Mapping

透過dispatcher-sevlet.xml,

利用context:component-scan去掃描package以下的所有@Controller,

那要如何將USER傳送的request對應到符合的控制器,

便是依賴@RequestMapping,

有以下幾種方式可以使用:

1.利用URL對應

可以在function前利用@RequestMapping來對應傳送的URL,

2014年3月9日 星期日

Clean Code - Meaningful Names

在coding的過程中,

命名一直是大家常常討論的事情,

不論是package、class、jar、file、document、properties等等,

這邊分享一些書中提到的觀念,

我想寫程式的方式每個人都有自己的想法,

看到別人提出的論點可以多聽多看多了解,

覺得好的可以學起來用,

但不認同的也可以提出來討論,

畢竟這也不是聖經或是spec,

不會有人逼你一定要用,

在此將一些覺得不錯的條列如下:

1. 名符其實

每一段Code中的所有變數,應該要可以解答所有讀者的疑惑,

可以比較以下兩段程式碼,第二段會比第一段容易理解每個變數代表的涵義,

很常看到在宣告m這種變數後,再寫一段註解解釋m是什麼意思,

如果這樣的話,不如直接宣告為month更顯得淺顯易懂。
        int m;
        String str;
        List<Integer> list=null;
 
        int month;
        String memberName;
        List<Integer> memberList=null; 

2. 有意義的區別

不要使用會讓人搞不清楚的命名,例如Member和MemberInfo兩個類別,

直覺上看起來是一樣的,或是使用a、an、the這種名稱,

像account和theAccount,或Item和ItemObject。

3. 可被搜尋

當一個變數或常數在程式中很常用到,最好給一個容易被搜尋到的名稱來代替,

比較以下兩段程式碼,for迴圈中的數字,

當使用變數名稱取代後,會更好搜尋及了解涵義。
  int sum = 0;
  for (int i = 0; i < 10; i++) {
   sum += i * 2;
  }

  int total_item_count = 10;
  int item_exchange = 2;
  for (int i = 0; i < total_item_count; i++) {
   sum += i * item_exchange;
  }

4. 類別和方法的命名

類別的命名盡量使用名詞,例如Member、Account、Item等等,

方法的名稱則使用動詞,例如save、update、delete、add等等,

取出使用get,設定修改用set,判定或flag使用is。

5. 避免雙關語

有時候你會常常使用add這樣的名稱,

不論是增加、插入、附加等等,

但你可以考慮用add、insert、append等等的命名來區別這其中的差異,

可以幫助讀者更好理解。

2014年1月19日 星期日

HQL 使用簡介

HQL是官方推薦的查詢語法,

有點類似SQL,

比較不同的是所使用的查詢指令,

都是依照物件的屬性和類別名稱,

必須用物件的方式來下HQL指令,

簡單的查詢指令如下:
   
   Query query = session.createQuery("from Member m");
   List<Member> list = query.list();

   for (Member m : list) {
    System.out.println(m.getName() + "\t" + m.getAge());
   }

Criteria 查詢方式

在hibernate中,

你可以使用criteria的查詢方式,

不需要下SQL或HQL指令,

也可避免因為換資料庫造成SQL的不相容,

而需要重新改寫SQL的負擔,

最簡單的查詢方式如下:
   Criteria criteria = session.createCriteria(Member.class);
   List<Member> list = criteria.list();


2014年1月14日 星期二

雙向多對多 XML Mapping

在多對多的配置中,

會採用一個中介表來記錄對應的資料,

最常見的就是使用者(User)與角色(Role)的多對多配置,

一個User可以有很多種Role,

一個Role也對應很多個User,

可參考下圖:











2014年1月13日 星期一

單向一對多 XML Mapping

如果今天考慮一對多的配置模式,

例如一個老師教很多位學生,

如下圖:












單向多對一 XML Mapping

如果今天兩個資料表考慮的情況是多對一,

例如員工跟部門,

多個員工屬於同一個部門,一個部門有許多員工,

如下圖:













2014年1月11日 星期六

雙向一對一(唯一外鍵關聯) XML Mapping

假設今天一個供應商對應一個銀行帳戶,

但這兩個table有各自的primary key,

我們可以考慮在供應商的table裡面,

增加一個外鍵欄位來連結銀行帳戶,

參考以下的供應商(Supply)和銀行帳戶(BankAccount)的關聯圖,










2014年1月9日 星期四

單向一對一(主鍵關聯) XML Mapping

在hibernate的一對一配置中,

如果你採用的是如下的主鍵關聯方式,











可看到人和車的一對一關聯設定,

並且採用的是同一主鍵關聯對應,

2014年1月6日 星期一

JSON 格式介紹及範例

以前的交換訊息格式都是採用XML,

最近在使用AJAX時接觸到了JSON,

格式更簡單明瞭,而且剖析也更方便了,

先簡單介紹一下JSON,

在寫JS時,可以用以下的方式宣告物件和陣列,

var person = {
 "name" : "David",
 "age" : 18
};
var people = [ {
 "name" : "Apple",
 "age" : 15
}, {
 "name" : "John",
 "age" : 25
} ];

2014年1月5日 星期日

SQL查詢的inner join & outer join

剛開始學習SQL時,

常聽到關於inner join和outer join的問題,

自己研究了之後,

用以下簡單的例子分享給對此有疑慮的開發者,

Table Member











Table Dept









一般的inner join,

指的是兩個table都有相互對應到資料,

簡單的說就是只會查詢出交集的部分,

SQL語法通常會這樣下:

select * from member m,dept d where m.dept=d.no

查詢結果









可以看到查詢出來的結果,只有兩邊有交集的部分,

member的Daniel和dept的machine因為沒有交集所以不會列出來。

在outer join的部分,分成left join和right join,

left join以左邊table為主,附加對應出右邊table的資料,沒有的顯示null

right join 則以右邊table為主,附加顯示左邊table的資料

如果以下left join語法查詢

select * from member m left join dept d on m.dept=d.no

查詢結果










可看到Daniel的部門E7無法在dept裡找到資料,則顯示為null

如果用以下的right join語法查詢

select * from member m right join dept d on m.dept=d.no











在dept裡的W0 machine也因為對應不到member的人員資料而顯示為null。