リスキルテクノロジー

「コメント」の重要性

From: リスキルテクノロジー 高坂一城
新宿本校にて

kohsaka

プログラミング言語を学ぶとき、
「コメント」は最初に習う項目の一つです。

「コメント」とは、
「ソースコードに書かれている注釈」 です。

そのため、コメントがあろうがなかろうが、
実際のプログラムの動作には全く
影響を及ぼしません。

プログラムを実行するときには、
コメントは全て無視されます。

では、なぜコメントを書くことが
必要なのでしょうか。

ある、調査機関によると、

「ソースコードの平均19%がコメントである」

という調査結果が出ています。

なぜ「コメント」が必要か

その理由は、
「ソースコードをメンテナンス(保守)する人に
情報を伝えるため」
です。

多くの場合、プログラムを作成する人と
そのプログラムをメンテナンスする人は異なります。

どんな「コメント」を書けばいいのか

では、どんなコメントを書けばよいのでしょうか。

今までに私が見てきたコメントで一番多いものが、

「何をしているコードなのか」

というものです。

例えば、

「ここでファイルにデータを出力する」
「もし値が0ならばエラー処理する」  などなど...。

このようなコメントは必要なのでしょうか??

「何をしているコードなのか」は、
ソースコードを見ればわかることです。

「コメント」として書くべきこと

ソースコードをメンテナンスする人が知りたいのは、

「なぜそのようなコードになったのか」

です。

ソースコードに手を入れて変更するにも、
なぜそのようになっているのかが
解らないと手を入れられません。

一見すると回りくどいソースコードだけど、
もしかしたら何か理由があるのかも?

そう考えると迂闊に手は入れられません。

「何をしているコードなのか」は、
時間をかければ読み解くことができます。

しかし、
「なぜそのようなコードになったのか」は、
そのソースコードを書いたプログラマの
頭の中にしかありません。

その意図をソースコードから読み取ることは
できません。

だからこそ、コメントで補う必要があるのです。

「コメント」も成果物の一部

最初にも書きましたが、
コメントはプログラムの動作には影響しません。

実際にプログラマに話を聞くと、
「なんとなく」でコメントを書いている人も多いです。

しかし、
コメントもソースコード(成果物)の一部です。

また、ソースコードをメンテナンスする人への
大切な情報源です。

実際にプログラムを書く際には、
「なんとなく」ではなく、気を遣ってコメント
を書くようにしましょう。

--------------------------------------------
PS.これからITを勉強したいあなたへ
高坂も登壇!参加費無料のセミナーはこちら↓↓
IT業界セミナー・授業体験セミナー
--------------------------------------------

綺麗なコードを書くためには?

From: リスキルテクノロジー 高坂一城
新宿本校にて

kohsaka

「優れたプログラマが書くコードは綺麗である」

と、よく言われます。

これは私の経験上、真実だと思います。

では、「綺麗なコード」とは何でしょうか?

一言でいうと、「一定のルールで書かれている」ということです。

書き方が統一されていないコードは美しくありません。

また、書き方が統一されていても、
そのルールが美しくなければ意味がありません。

ということで、「美しい書き方のルール作り」が大切です。

名前の付け方

まずは名前の付け方を決めます。

全て英単語にする、といった場合、
以下の2つの表現方法があります。

【スネークケース】

単語と単語の間を"_"(アンダーバー)で区切る方法です。

例えば、「ユーザ名を取得する(get user name)」ことを

get_user_name

と表現します。

これは単語を"_"でつなげる様(さま)が、
スネーク(蛇)に似ていることから名付けられています。

【キャメルケース】

単語の頭文字だけ大文字にして連ねる方法です。

上記の例では、

getUserName

と表現します。

これは大文字の部分がキャメル(らくだ)の"こぶ"の
ように見えることから名付けられています。

基本は使用する言語に合わせる

名前の付け方(単語の区切り方)は、
使用するプログラミング言語に合わせます。

一般的に、Javaならキャメルケース、
Rubyならスネークケースが綺麗とされています。

「綺麗なコード」は、見返りの大きい、時間の投資

名前の付け方を考えて綺麗なコードを書くには、
時間がかかります。

10行や100行のコードをただとりあえず動くだけの
レベルで書くのに比べたら、余計に時間はかかります。

さらに、動いたらメンテナンスせずに捨ててしまうプログラムなら、
「綺麗」にこだわっても意味がないですよね。

しかし、たいていのプログラムは、10行や100行を
書いて終わりではないです。

実際は、もっともっとたくさんのコードを書き、
それをメンテナンスしなくてはいけません

(スマートフォンの中にはおよそ1億行のプログラム
が入っていると言われています)。

そこで綺麗なコードのために費やした時間に、
メンテナンスのし易さ、
という膨大な利子が付いて返ってきます。

さらに、綺麗なコードを書くために、
プログラムを整理することは、

こだわった分だけ、
そのプログラマ自身のスキルを確実に向上させます。

例えば、今、綺麗なコードを書くために10の時間がかかっても、

次は9の時間でそれができ、その次は8の時間で、というように、

投資に必要な時間がどんどん短くなっていきます。

投資額が少なくなる一方、見返りがどんどん増えていく。

こんな美味しい投資をしない手はありませんよね!

--------------------------------------------
PS.プログラミングを学ぶなら
LAプログラマースクール
--------------------------------------------

プログラムの正しい書き方とは?

From: リスキルテクノロジー 高坂一城
新宿本校にて

kohsaka

「プログラムの正しい書き方ってあるのでしょうか?」

プログラミングを
学び始めて間もない方から
先日このような質問を受けました。

さて、
そもそもプログラムに...

「正しい書き方」

...はあるのでしょうか?

プログラムって動けばいいの?

プログラムの
正しい書き方というのは
もちろんありますが...

「これが絶対的に正しい!」

...という
明確なものがあるかというと
ちょっと悩んでしまいますね。

エンジニアとして
活躍されておられる方なら
誰もが一度は...

「動けばいいから」

...という言葉を
聞いたことがあるかと思います。

これはプログラムの中身はどうあれ、
システムとして期待している

機能や結果が出ていれば
問題ないよという意味で使われます。

決してシステムの中身が
どうでもいいという訳ではありません。

じゃあ何が「正しい」ってことなの?

いきなりたとえですが...

例えばあなたが
小説を読み始めたとします。

せっかくの休日。
ゆっくりとした時間を取ろうと考えて、
本屋に行って買ってきました。

しかし、
読んでみると、、、

全然理解できない。
前後の文脈が合っているような、あっていないような、、、

「ああ、それが言いたかったのね」

...と後半になってやっと理解できるような
文章だったりすると疲れてしまいます。

ポイントはここです。

正しいプログラムの書き方のポイントも
小説などの文章と同じくここにあります。

まずひとつめは...

1.理解しやすい書き方かどうか

...ですね。

小説でも新聞記事でもそうですが、
文章は読みやすい方がいいです。

プログラムも
文章みたいなものです。

処理そのものはコンピュータがしますが、
人が書いて人が読むものです。

意図が伝わりにくいよりも
伝わりやすい方がいいのです。

システム開発は多くの場合
1人だけでするものではありません。

多くのエンジニアが
集まってシステムを作り上げます。

あるエンジニアが書いたプログラムが
非常に分かりにくいコードで、

そのエンジニアから

「設計書ないから、ソース読んで理解してね」

...と言われても、
言われた方が困りまってしまいますし、

効率の良い開発が行えなくなります。

そしてもうひとつのポイントは...

2.適切な書き方かどうか

...ということです。

処理結果が同じであっても
書かなくても良いことを書いていたり…

書かない方が良い
内容を書いたりしている場合、
そのときは動いていても、
何らかのバグの原因になりかねません。

プログラム言語は
書き方によってはどんな処理もできますが、

プログラム的には
あまり使わない方がいい書き方もあるのです。

javaの例を見てみましょう

簡単な内容ですが、
javaのコード例を少し見てみましょう。

例えばこちらは
雑貨、医薬品、衣類の売り上げを合計し、
平均売上高を出すロジックです。

int a,b,c,t,v;
a = 320000;
b = 200000;
c = 130000;
t = a+b+c;
v = t/3;

コードは短いですが
変数名がa,b,c,t,vとなっています。

これだとぱっと見ただけでは、
変数か何の値を扱うかが分かりにくいですね。

これをこのように書き換えます。

int salesItem = 0;
int salesDrug = 0;
int salesWear = 0;
int total = 0;
double salesAvl = 0.0;

salesItem = 320000;
salesDrug = 200000;
salesWear = 130000;
total = salesItem + salesDrug + salesWear;
salesAvl = total / 3;

変数名をしっかり設定するだけで
何の値を扱う変数か、
どんな処理をしているかがよくわかります。

続いてはこちら、乱数の計算です。

double totalValue = ((Math.random() * 10 )+(Math.random() * 20)-(Math.random() * 5)+(Math.random() * 15));

4つの乱数を加減算していますが、
1行でまとめてしまうと
ちょっと長くて読みにくいです。

これくらいならまだ読めますが、
もっと長い処理を1行で書こうとする
エンジニアもいらっしゃいますね。

double firstValue = Math.random() * 10;
double secondValue = Math.random() * 20;
double thirdValue = Math.random() * 5;
double fourthValue = Math.random() * 15;

double totalValue = firstValue + secondValue - thirdValue + fourthValue;

こちらはこのように書き換えると
乱数との積を求める値もわかりますし、
パッと見て理解できるかと思います。

続いては条件文です。

public boolean checkTarget(int targetValue){
if (checkValue1(targetValue) == 0){
if(checkValue2(targetValue) == 0){
if(checkValue3(targetValue) == 0){
if(checkValue4(targetValue) == 0){
if(checkValue5(targetValue) == 0){
return true;
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}

checkValue1~5の
5つのチェック全てにおいて
値が0かどうかをチェックしていますが、

ネスト(入れ子)が多すぎて
わかりにくいですね。

同じ処理をこのように書き換えると
見づらさは解消されます。

public boolean checkTarget(int targetValue){

boolean ret = false;
if(checkValue1(targetValue) == 0 &&
checkValue2(targetValue) == 0 &&
checkValue3(targetValue) == 0 &&
checkValue4(targetValue) == 0 &&
checkValue5(targetValue) == 0 ){

ret = true;

}
return ret;
}

最後にもうひとつ、
こちらはオブジェクト指向的な話です。

public class classA(){
public int ValueA = 0;
public int ValueB = 0;
...
}

このようなクラスがあります。

public変数はどのクラスからでも
参照できるものですが、

クラスの依存性が明確になりませんし、
カプセル化の観点からもあまり良いとは言えません。

public変数は
そのクラス内からのみ参照できる
private変数に変更して...

setter、getterと呼ばれる
値の設定と取得を行うメソッドを設定しましょう。

public class classA(){
private int valueA = 0;
private int valueB = 0;

public void setValueA(int _valueA){
valueA = _valueA;
}
public int getValueA(){
return valueA;
}
...
}

...こんな感じですね。

エンジニアとしての質を高める

このように
書き方ひとつで読みやすさが
段違いに変わってきます。

読みやすさが向上すると
メンテナンス性が高まりますので、

長い目でシステムを見た時に
バグが発生する可能性が低くなるのです。

このような
プログラムの取決めは

「コーディング規約」

にまとめられています。

javaの場合は
いくつかの団体が
コーディング規約を公表しています。

日本の企業でも
公表している企業がありますが、

開発経験が長い企業だと
独自のコーディング規約を作っている企業もあります。

プログラムをプロダクトして考えると
プロダクトの質を高めることが大切です。

その質を高めるためには
コーディング規約などによって

読みやすさや適切な処理などを
高める必要があります。

もちろんコーディング規約だけが
質を高める要素ではありません。

システムとして総合的な質を高めるには
プロジェクトの進め方や設計手法など
さまざまな要素の質を高めなければなりません。

全ての質を高めるには
多くの時間と経験が必要になりますが、

まずは基本となる...

「プログラムの質」

...を高めることから
エンジニアとしての意識を高めてゆきましょう。

 

PS

プロフェッショナルになるプログラミング講座はこちらから

ミスのない設計をするには?

From: リスキルテクノロジー 高坂一城
新宿本校にて

ミスのない設計をするには
どうすればいいか?

これは
全てのエンジニアにとって
命題と言っても過言ではないでしょう。

今回は
設計ミスを無くすために
何が必要かをご紹介します。

設計ミスは無くせるか

ミスのない設計をする!

と意識して
いざシステム設計してみたが...

実際には
さまざまな設計ミスが
システムの陰に潜んでいた....

そんな経験を持つエンジニアの方は
多いと思います。

設計ミスは100%無くせるのか!?

答えは残念ながらノーです。

人間が作るものですから
必ずどこかにミスが潜む可能性はあります。

なんだ、
やっぱり設計ミスはなくせないんだ...

なんて思わないでください。

そもそも

「無くせるか無くせないか」

という、
「0」か「1」で考えることに
無理があるのです。

設計ミスを防ぐにあたっては

ミスを無くす!

と考えるのではなく、

設計の品質を高める!

と考える方が遥かに建設的です。

システムと言えども
所詮は人間が作るものです。

言わば「ものづくり」ですね。

どのような
ものづくりでもそうですが、

品質の高いものをつくることが
ユーザーの評価に繋がりますし、

品質の高いものをつくることで
作り手(エンジニア)を育ててくれます。

とはいえ、
もちろん設計ミスは
無いに越したことはありませんよね。

設計ミスを
限りなく0に近づけるとともに

システムとしての
品質を高める姿勢こそが
エンジニアにとって重要なのです。

勘違いしてはいけません

設計品質を高めるために
勘違いしてはいけないことがあります。

それは...

「○○制度を導入しているから品質は高い」

...と言う点ですね。

○○には
設計手法であるとか
設計文書管理の規約であるとか、

テンプレート的な
手法や方法があてはまります。

確かに
一般的に広く使われている
制度や手法を導入することで

品質には一定の
ベースアップが見込めます。

それは非常に大切な事であり
導入することで品質が高まるのであれば
迷わず導入することをオススメします。

ですが、

「それを導入している=品質が高い」

という考えるのは誤りです。

制度や手法は
ある面では大きな効果を生みますが

その制度や手法に
そぐわないアイディアは実行しにくいという
ある種の縛りも生みます。

さらに、
品質を最大限に高めるのは

制度や手法といった
実体のないものではなく、
あくまでエンジニアという人間です。

システム開発を
1人で行うケースは非常に稀です。

制度や手法だけに頼らずとも
さまざまな経験やスキルを持った
エンジニアが必ずそばにいるのです。

制度や手法がもたらしてくれる
メリットを最大限に利用しつつ...

エンジニア同士が協力しあうことで
設計品質を高めることができます。

どうやって品質を高めるのか

設計品質を高めるために
エンジニアに必要な心がけを
いくつかご紹介しましょう。

ある程度の品質が保証されているものを利用する

これは先ほどの
制度や手法のメリットを
利用するということに繋がります。

たとえば設計書であれば
先日ご紹介したUMLを利用するのがいいですね。

UMLは
オブジェクト指向設計のために考案された
モデリング言語ですので、

多くのエンジニアが...

「こんな設計書があれば理解しやすいのに」

というニーズに合わせて
進化し続けている設計書の表現方法です。

また、実装段階では
デザインパターンを利用するのもいいですね。

デザインパターンとは
プログラムを実装する際に

特定のパターンでプログラムを書けば
問題なく実装できるといった
パターン集のことです。

デザインパターンについては
また別の機会に話しますが、

デザインパターンも
多くのエンジニアが
品質向上のために編み出した手法です。

もちろん、
UMLやデザインパターンだけで
ベストだということはありません。

UMLはシステム内外の
処理の流れや仕様を把握できますが、
それだけでは足りないケースも割とありますし、

デザインパターンは
あくまでパターンですので、

実装する時には
システムに合わせる必要があります。

レビューで設計品質を高める

あるエンジニアが設計した内容は
そのエンジニアの視点で作成されたものです。

特定のエンジニア視点だけだと
設計ミスが含んでいる可能性が高まりますので、

多くのエンジニアと設計レビューすることで
設計ミスを0に近づけることができます。

レビューは自分以外のエンジニアの
スキルや視点を反映できるチャンスです。

それだけで
設計品質を大きく高めることができますので、

できるだけ設計レビューの機会を
設けることをオススメします。

ここでひとつ注意したいのが...

レビューの形式化

...です。

レビュー回数が多くなりすぎて
レビューそのものが形式化してしまうと、

折角レビューをしたとしても

「うん、まあ大丈夫だろう」

...と、レビューを受ける側も
細かい判断を放棄してしまうことがあります。

これだと意味がありませんので、
レビューする側は淡々とレビューするだけでなく、

時には他のエンジニアに問いかけるような
工夫を織り交ぜながら行うようにしましょう。

チェックシートを活用する

これ、意外ですけど
結構品質を高める効果はあります。

建設業や旅客業など、
一歩間違えれば大事故に繋がる業種では
今でもチェックシートが活用されています。

システムについて
共通的に考慮すべき事項や、

システム固有の特徴から
チェックする必要がある項目をまとめ、
設計内容をチェックしてゆきます。

品質を高めるために行っていることが
正しく行われたかどうかを確認するフェーズですね。

時間的な問題から
十分に行われていない項目があれば
そこにミスの可能性が含まれている訳ですから、

システム開発で行った行動の
どの部分に懸念材料があるのかを把握できます。

その懸念材料に対して
後日にでも対策することで
高い品質を確保することができるのです。

今やシステム障害が発生したら
何億という被害や
社会的な信頼を失いかねない時代です。

このような大事故を防ぐことができるならば
大きな手間ではありません。

基本はエンジニア間のコミュニケーションです

設計ミスを0に近づけるために
設計品質を高めるためにできることは

他にもたくさんありますし、
企業によってさまざまな工夫が施されています。

いろいろ書きましたが、
やはり基本となるのは
開発チーム内のコミュニケーションです。

制度も手法も
レビューもチェックシートも
活用するのはエンジニアという人ですので、

高度な技術を持っているけど
コミュニケーションに問題があったりすると、
メリットを最大限に引き出すことができません。

実際に
設計書もそこそこしかない
小さなソフトハウスだけれども、

設計ミスやシステム障害が
非常に少ないという企業もあります。

そういうところは
エンジニア間のコミュニケーションが
抜群に良いんですよね。

チームとして意思疎通が取れていて、
スキルの共有もできているので、
設計ミスを早期に発見できるのです。

高い品質のシステムを作る!

という目的意識を持ちながら
開発チームでスキルを共有できる...

それが
最善であり基本となる
設計ミスを防ぐ方法なのかも知れません。

リスキルテクノロジー
松田

PS

プロになるためのプログラミングの講座はこちらから

統一モデリング言語-UMLとは?

From: リスキルテクノロジー 高坂

ソフトウェアの
開発現場においては、

さまざまな手法で
設計書が作成されています。

今回は
最も広く普及している
設計書の表現手法である...

「UML」

...についてご紹介しましょう。

設計書の表現はさまざま

言葉というものは
使い方や言い回しひとつで

さまざまな表現を
することができます。

言葉の使い方は
人によってさまざまですので

極端な話をすれば
100人いれば100通りの表現があります。

では、
プログラムの設計書の場合を
考えてみましょう。

設計書も同じく
100人書けば100通りの
設計書が生まれる可能性はあります。

しかし、
プログラムの設計をするのに
100通りの書き方が存在すると、

必ずしも期待通りの
プログラムが書かれるとは限りません。

プログラマーが読み違えて
設計で意図していない
プログラムが生まれる可能性もあります。

そしてこのような現象は
実際に開発現場で起きています。

さまざまな企業の
開発を経験するSIerや、

転職経験のある
エンジニアならご存知かと思いますが、

開発現場や企業によって
実際に設計書の書き方が
大きく違うというケースは多いのです。

このような

「違い」

...をできるだけ無くし、
統一された書き方が生まれました。

それが...

「UML」

...なのです。

表現を統一すれば理解しやすい

UMLとは

Unified Modeling Language

の略称で...

Unified(統一された)
Modeling(モデリング)
Language(言語)

...という意味です。

「統一モデリング言語」

と和訳されていますね。

オブジェクト指向開発における
統一された設計書の表現方法については

1990年代ごろから
さまざまな方法が考案されてきましたが、

検討を重ねて
それらのさまざまな方法を
ベースにして生まれたのがUMLです。

UMLには多くのメリットがあります。

たとえば
表現方法の統一されている点です。

設計書の表現方法が
統一されているので、

UMLの読み方を理解している
エンジニアであれば
設計仕様を正確に読み取りやすくなります。

また、
UMLは文字だけの仕様記述ではなく、

基本的に図(ダイアグラム)で
仕様を表現しているため、
エンジニアにとって理解しやすいですし、

設計変更が起きた場合でも
どのプログラムを変更する必要があるのかが
把握しやすくなります。

UMLのダイアグラム

UMLには用途によって
いくつかのダイアグラムがあります。

システム構造に関するダイアグラム

■1:クラス図

システムを構成している
クラスの関連性を表現したものです。

あるクラスが
どのクラスとどのような関係があるのか、
どのような変数を保持しているのかなどを
視覚的に理解することができます。

■2:パッケージ図

複数のクラスが集まって
ひとつのパッケージが構成されますが、

そのパッケージの関連性を
表現したダイアグラムです。

■3:オブジェクト図

クラス図ではクラス間の
関連性を把握することができますが、

オブジェクト図では
実際にプログラムが動作する際に
どのような状態になるかを表現します。

システムの振る舞いに関するダイアグラム

■4:アクティビティ図

プログラムの処理の流れを
表現するダイアグラムです。

「フローチャートのUML版」と言えば
理解しやすいかも知れません。

■5:ユースケース図

システムの利用者(アクター)が
システムの利用の仕方や、

システムがアクターに対して
提供する機能を表現します。

■6:ステートチャート図

システムがある処理を行う際、
オブジェクトの状態に
どのような変化が起きるのかを表現します。

ステートチャート図は

「状態遷移図」

と呼ばれることもあります。

システム間の相互作用に関するダイアグラム

■7:シーケンス図

オブジェクト間の連携や
動作の流れを表現するダイアグラムです。

イベントが起きた時に
どのような流れで処理が進むかなどを
表現しています。

■8:コミュニケーション図

オブジェクト間での
メッセージやデータのやりとりを
表現したダイアグラムです。

オブジェクト間で
実際にどのようなデータが
受け渡しされるのかを理解できます。

「コラボレーション図」

と呼ばれることもありますが、
これは古い呼び方です。

習得することをオススメします

この他にも
さまざまなダイアグラムがありますが、

主に使用されているのは
ここで紹介したダイアグラムになります。

これから
プログラムを学ぶ方にとって
UMLを学ぶことは大きなメリットがあります。

UMLはシステムの構成や動作を
俯瞰的に見ることができますので、

プログラムだけでなく
システム全体を理解しやすいのです。

しっかりとした
開発スキルを身に着けたいならば
UMLの習得することをオススメします。

UMLは、
あなたが実際に
プログラムを作る時だけでなく、
設計する時にも役立つ手法なのです。

リスキルテクノロジー
高坂

PS

UMLも学べるプログラミングのスクール

Eclipseを日本語化しよう

From: リスキルテクノロジー 高坂
@新宿本校

以前のブログで
IDE(統合開発環境)

「Eclipse」

...をダウンロードしました。

今回は実際に
Eclipseを起動してみましょう。

Eclipseを起動しよう

以前のブログでは
Eclipseをダウンロードし、

ファイルを展開したとこで
終了したいました。

Eclipseを動かすには
これからインストールや設定が必要!

…という訳ではなく、
展開したファイルを実行するだけで
起動することができます。

それでは
起動してみましょう。

ファイルを展開したフォルダ

/user/eclipse

に移動して、

eclipse

のアイコンをダブルクリックします。

step1

Eclipseが起動しました。

しばらくすると、
スタート画面が表示されます。

step2

英語です。

そう、
Eclipseはデフォルトで
英語で表示されるのです。

英語がわかる方なら
特に問題ありませんが、

あまり馴染みがない方にとっては
開発中ずっと英語というのも
厳しいものがあるでしょう。

という訳で、
Eclipseを日本語化したいと思います。

PleadesでEclipseを日本語化

Eclipseは...

「プラグイン」

...と呼ばれる
拡張モジュールを追加することで
さまざまな機能を追加できることができますが、

Eclipseを日本語化するにも
このプラグインを使用します。

Eclipseを日本語化する
プラグインとしては...

Pleades

が有名ですね。

出典:MergeDoc Project

step3

こちらは
MergeDoc Projectにより
配布されているプラグインで、

本体だけでなく
他のさまざまなプラグインも
日本語化してくれるものです。

それでは
Pleadesプラグインを
Eclipseに追加してみましょう。

その前に、
今回も前回と同様、
管理者権限のユーザでログインしてくださいね。

まずは
プラグインを保存する
フォルダを作ります。

step4

/usr/eclipse/dropins/

のフォルダに...

pleades

という名前のフォルダを作ります。

そして
ホームページの中央付近に...

「Pleadesプラグイン・ダウンロード」

という欄がありますので、
安定版のリンクをクリックし、

pleiades_1.6.0.zip

をダウンロードします。

※2015/8/7時点でのバージョンは1.6.0

ダウンロードしたら
アーカイブマネージャで開きます。

step5

これらのファイルを
先ほど作ったフォルダに展開します。

step6

そして
Eclipseをインストールした
フォルダに移動し...

eclipse.ini

を開いて設定を変更します。

step7

ダブルクリックすると
geditが開きますので、

-Xverify:none
-javaagent:/usr/eclipse/dropins/pleades/plugins/jp.sourceforge.mergedoc.pleiades/pleades.jar

の2行の設定を
一番最後に追加して保存します。

これで準備は整いました。

Eclipseを起動しましょう。

step8

みごとに
日本語化されました。

もし、
うまく日本語にならない場合は、

コンソールか…

/usr/eclipse/eclipse -clean

とコマンドを入力して
起動してみてください。

それでもエラーが出る場合は
eclipse.iniの設定が間違っている場合があります。

設定ファイルの内容をチェックしましょう。

これで
言葉を気にすることなく
Eclipseが使えるようになりました。

次回はEclipseの
基本的な使い方などについてご紹介します。

リスキルテクノロジー
高坂

PS

日本語化しておいて何ですが…
エンジニアにはやはり英語力が必要です。

できるだけ英語に
慣れておくことをオススメします。

リスキルテクノロジーの資料請求はこちらから

Eclipseのインストール方法 -準備編-

From: リスキルテクノロジー 高坂
@新宿本校

システム開発に欠かせないのは...

IDE(統合開発環境)

...です。

優れたIDEを使うことで
開発効率をアップさせることができます。

以前に構築したCentOS7に
IDEのひとつである...

Eclipse

...をインストールしてみましょう。

注)CentOSでのインストールになります。

Eclipseとは?

Eclipse(イクリプス/エクリプス)は
IBM社で開発されたIDEです。

その歴史は
1990年代から始まりますが

2000年代に入り
オープンソース化されるとともに

多くの開発者の支持を得て
今でも様々な開発現場で使われています。

主に使用されるのは
Javaを使った開発ですが、

プラグイン

と呼ばれる
拡張機能を使うことにより

PHPやRubyなど
Java以外の言語で開発できます。

Eclipseとは

「日食」

...という意味です。

宇宙や天体を
イメージさせますが、

Eclipseの
各バージョンにも
天体に関連する名前が付けられています。

たとえば...

バージョン3.2には
木星の衛生「Callisto」という名前で、

バージョン4.4には
月を意味する「Luna」という名前です。

ちなみに、
最新バージョンである4.5には

Mars(火星)

...という名前が付けられています。

管理者としてCentOSにログインしておこう

今回は
CentOSにログインする時に

初めからRoot(管理者)で
ログインしておいてください。

step1

Rootでログインするには
ログイン画面が表示された時に

「アカウントが見つかりませんか?」

というリンクをクリックします。

次に表示される画面で
管理者のユーザー名とパスワードを入力します。

これで、
管理者としてGUIでログインできます。

ただし、
ひとつだけ注意があります。

管理者でログインする時は
システムで必要なファイルやフォルダを
誤って消したりしないように気を付けましょう。

場合によっては
システムが起動しなってしまいますので。

Eclipseをダウンロードしよう

まずは公式サイトから
Eclipseの最新版である...

Eclipse Mars

...をダウンロードしましょう。

出典:Eclipse

step2

32bit版と
64bit版があるので
環境にあわせてダウンロードしてください。

Step3

32bitか64bitかを選択すると
ダウンロード元のサイト情報が表示されます。

Downloadをクリックしましょう。

step4

ダウンロードが終わると
どのように開くかを聞かれます。

プログラムで開く-アーカイブマネージャ

を選択しましょう。

ダウンロードされたファイルは
アーカイブされたままです。

アーカイブとは
複数のファイルをまとめて
1つのファイルにしたものです。

また、
容量を減らすために
データを圧縮されています。

そういった
アーカイブを管理するソフトが
アーカイブマネージャなのです。

ダウンロードが終わると
アーカイブマネージャが開きます。

step5

eclipse-jee-mars-R-linux-gtk-x86_64.tar.gz

という
アーカイブの中に...

eclipse

というフォルダがあります。

フォルダを選択して

「展開」

...をクリックしましょう。

step6

展開画面が表示されます。

ログインユーザーの
ホームフォルダが表示されます。

一般的にプログラムは...

usrフォルダ
(/usr)

...に置くことが多いので、
usrフォルダに移動して展開します。

step7

展開が終わると

「eclipse」

というフォルダが作成されます。

Eclipseのダウンロードは
これで終了です。

次回は
Eclipseの起動と日本語化をご紹介します。

リスキルテクノロジー
高坂

PS

最初に管理者で
CentOSにログインしたのは

管理者以外のユーザーでは
usrフォルダに
ファイルを作成できない場合があるためです。

ファイルが作成できる、できないというのは

「権限」

…で管理されますが、
それについてはまた別の機会にご紹介します。

Javaプログラマーを目指すならこちらから

エンジニアのためのビジネス用語講座3

From: リスキルテクノロジー木村

エンジニアが
ビジネスシーンで使う
使いすぎ注意のビジネス用語を

これまで2回にわたって
ご紹介してきましたが...

今回もまた
エンジニアのためのビジネス用語講座を
開講したいと思います。

カタカナ語のビジネス用語って
本当に多いです。

問い

さて、
今回はビジネス用語の
問題から始めたいと思います。

それでは、
次の文の意味を答えてください。

・例題1

社員の情報リテラシーを深め、
シナジーを高めながら活動しましょう。

・例題2

今回の開発スキームにおいて
テスト工程におけるマイルストーンでは、
エビデンスをユーザに提示して
オーサライズしてもらう必要があります。

...意味がわかるようで
はっきりとわかりにくいですよね。

これらは過去のブログで
ご紹介した用語になります。

それでは
解答を見てみましょう。

・例題1の解答

社員の情報に対する理解度を深め、
社員同士の相乗効果を高めながら活動しましょう。

・例題2の解答

今回の開発計画において
テスト工程におけるそれぞれの節目では、
テスト結果となる成果物をお客様に提示して
承認してもらう必要があります。

だいたい
こんな感じの意味になります。

解答できましたでしょうか?

カタカナ語だと
意味が伝わりにくいですが、

日本語でも
やや固い言い方になりますね。

そのあたりも
カタカナ語が使われる
理由のひとつと言えるでしょう。

エンジニアのためのビジネス用語集3

それではさっそく
紹介してゆきたいと思います。

■1:インスコ(?)

・使用例
「プログラムをインスコしといて」

・意味
「インストール」

これは和製英語のようなもので、

「インストール(install)」

...のことを言います。

「インストール」

「インスト」

「インスコ」

...と、
標準語から地方の方言に変わるように
表現が変わってゆきました。

インストール作業が多い
IT業界でよく使われています。

■2:ネゴ(nego)

・使用例
「その件は部長にネゴってください」

・意味
「交渉」「協定」

こちらも和製英語のようなもので、

「ネゴシエーション(negotiation)」

...が短くなった言葉です。

上司やユーザーなど、
相手との交渉が必要なときに使われます。

■3:ブラッシュアップ(brushup)

・使用例
「その企画をもう少しブラッシュアップしましょう」

・意味
「磨き上げる」「質を高める」

ものごとを磨きあげることで
質を高めることを意味します。

ある程度の
レベルに到達したけれど
もっと質を高めたい時に使われますね。

■4:ペンディング(pending)

・使用例
「その件についてはペンディングとします」

・意味
「保留」「未定」

諸事情により
ものごとがうまく進まず、
保留状態になっていることを意味します。

「pend」

という言葉は

「ぶら下がる」

...という意味ですので、

「ものごとがぶら下がったまま」

...という意味で使われています。

■5:ボトルネック(bottleneck)

・使用例
「何がボトルネックになって遅れているのですか」

・意味
「詰まる」「(速度が)落ちる」

システム用語では
設計上の制約や速度が低下する処理などを
意味しますが、

一般的なビジネス用語としても
ものごとが進まない原因を指す言葉として
使われています。

ボトルネックとは
瓶の細くなっている首の部分のことで、

液体がそこを通る時に
流れが遅くなることが語源になっています。

■6:ミッションクリティカル(mission critical)

・使用例
「ミッションクリティカルなシステム」

・意味
「常に稼働する必要があるシステム」

電気などのライフラインや
交通系・金融系システムなど、

24時間365日の稼働が必要で
停止することができないシステムを意味します。

■7:リスクヘッジ(risk hedge)

・使用例
「問題が発生した時のリスクヘッジを教えてください」

・意味
「危険回避」「損失回避」

もともとは
金融や経済用語として使われていましたが、

計画の立案などにおいて
問題が発生した場合の回避策を表す言葉として
使われています。

システム開発でも
開発計画を立てるときに使われますね。

■8:リスケ(resche)

・使用例
「そのスケジュールをリスケしてください」

・意味
「再計画」

リスケとは…

「リスケジュール(reschedule)」

...の意味で、
もう一度計画しなおすことを言います。

システム開発では
開発に遅れが発生した場合、

当初の計画を
修正するケースがありますが、
そのことをリスケと言います。

海外では通じない用語もあります

エンジニアが使う
ビジネス用語はたくさんありますが、

今回ご紹介したように
和製英語のように使われているものもあります。

海外のエンジニアなどには
意味が通じないケースもありますので
注意してくださいね。

さて、
これまで3回にわたって...

「エンジニアのためのビジネス用語講座」

...を開講しましたが
いかがでしたでしょうか?

まだまだご紹介できる
用語はたくさんあるのですが…

またの機会に
改めてご紹介してゆきたいと思います。

PS

エンジニアになるためのスクールならこちら

未経験からの育成制度も充実
IT講師に興味はありませんか?

リスキルテクノロジーでIT講師の積極募集を開始! 経験・未経験問わずご応募可能。育成制度で講師スキル向上も目指せます

IT講師に応募する