適当にmysqlでも……(長田研アドベントカレンダー9日目)

せいなる夜にこんばんわ。

宜保 行平@M2です。

 

自分がこのブログに書くのは何ヶ月振りでしょうか?

書く内容無いからっていって、断ってたのですが回ってきちゃったので必死に内容考えてます。

とりあえずこの辺は先に書いてタイトル決めて内容決めてます。

 

閑話休題

さて、前置きはこの辺にして何書くかなーってことでまぁタイトルな感じのやつをチョイス。

正直なとこ、ちょっと調べればまぁわかる内容的な基本的なことをつらつらっと書く感じなので適当に流し読みする感じでお願いします。

そもそもチョイス理由も書く内容無いなー、研究のやつ書くのもなんか違うなー、って感じで研究を弄っててこれでいっかって感じですし。

調べたらわかることを書くのもどうなのかってのはアレですが、そこは他の長田研メンバーがふぉろーしてくれるよね……

 

Mysqlとは何ぞや?→データベース

はい、なんかこう説明になってない説明をまず最初に。

んじゃデータベースって何なのよって聞かれるのが明らかな回答ってどうなんだろうか。

データベースってのは、データを検索とかしやすくする為の仕組みで、例えば琉大周辺のご飯どころのデータ群があって一番安くてたくさん食べられるとこが知りたい、って時にすぐぱっと調べる為のものです。

 

この仕組みってどこで使われてるの?→すぐ目の前

この長田研のブログで使われてるwordpressっていうのにも使われてて……あれ、これはmysqlだっけか?まぁ何かしらのデータベースは使われてたはず、はず。

まぁようは、見えないところで動いてますよ。

他にもいろんなところで使われてるので気になる人は調べてみればいいんじゃないかな。

 

データベース使ってみたい→簡単にやりたい情報工生はVM借りてみよう

確かデフォルトでインストールされてたはず、バージョンは定期的にアップデートしてたかな?それなりに新しいはず。

VM借りたらor借りてたら、root権限があればservice mysqld startぐらいを実行すれば起動するはず。

電源が切れるたびに再起動するように設定してもいいだろうけど。

 

起動したらどうすんの?→ログインして、データベースつくって、テーブル作って、データ入れたり出したりあふれるぐらい使ってみればいいんじゃないかな

本当はここメインに書いた方がいいんだろうけど、いろいろ書いてて憑かれた。まぁその辺は調べたりすればすぐ見つかるしなぁと言い訳。

mysqlにアクセスしたらcreate databaseでデータベースつくって、useでそのデータベースにアクセスして、create tableでテーブルつくってそのテーブルの中にinsertでデータを挿入するだけ、なんてかんたん(棒

テーブルの中に入ってるデータを検索する時はselect文使ってとかその辺か。

 

色々と説明はしょり過ぎ→自分で調べるか、授業受ければいいんじゃない?

ググればすぐに初心者でもわかる的なのが見つかるはずだし、確か授業でデータベースもあったはず……受けたことないからどんな授業かわかんないけど。

抜けてたり間違ってることも書いちゃってそうなあれだし、こういうのは自分で調べて実際やってみるのが一番身に付くと思います。

 

終りに

なんか微妙なテンションで書いてるから変なことばっか書いてるなー。もうちょい真面目に書くべきだったか。

普段はこんな人じゃないですよ。多分。

もうちょいたくさん書くべきなんだろうけど、精神的なダメージがでかい日なのでごめんなさい?

さて、次は順番的に許田さんかな?

よろしくお願いします。

CSSの基本から その2 (長田研アドベントカレンダー8日目)

こんにちは。
大城佳明@M1です。

CSSの基本から その2ってことで、今日はツールの使い方を書こうかと思います。
CSSをイジる上でいろいろなツールがあるかと思います。
CSSのコードをイジる場合、他の言語と違ってエラーを吐かないのが辛いです。
「あれ?CSS適応されてないんだけど!?」というようになることが多々あります(汗)
原因は色々とあります。
タイプミスだったり、セミコロン忘れてたり、ファイルの読みこむ順番だったり、組み合わせることで使えなくなるやつだったり。。。
(なにが原因がわからないのが一番辛い)

そんな時、ツールがあると比較的楽(精神的に)にCSSを書くことができます!
今回紹介するのは「Google Chrome Developer Tools」です。
FirefoxユーザとしてはFirebugを使うべきなのでしょうが、自分は開発するときだけChromeを使ってますw

まず、Google Chrome Developer Tools を開きましょう。
「表示」→「開発/管理」→「デベロッパーツール」
「option + command + i」でも開けます。
blog20131223

そうすると以下のようなウィンドウが現れることでしょう。
スクリーンショット 2013-12-23 6.10.11

(自分は横のほうが好きなので、横に持ってきます)

Developer Tools のソースコードにカーソルを合わせるとhtmlのどの部分かをみることができます。
2013122301

CSSをいじるのに大事なのは下の部分。
ここでCSSを変更することが可能なのです。
スクリーンショット 2013-12-23 6.39.58

例えば・・・
#main に background-color: red; を追加してみましょう。
スクリーンショット 2013-12-23 6.43.15
そうすると、以下のように一部背景が赤に変わりました。
2013122302

このようにCSSを追加するとにより、実際にどのように変化するかを見ることができます。
ちなみに、CSSのファイルが複数があったり、ファイル内の複数の場所で指定されている場合優先順位が付きます。
Developer Tools では上が一番優先度が高く、すぐに反映させたいならば一番上が良いです。
2013122303
ただし、element.styleはhtmlに直接書くことになります。
この部分だけ反映させたい!!って時に書くのが良いかと思います。
詳細はCSSの基本から(長田研アドベントカレンダー1日目)

もっと書く予定ですが、疲れてきたので残りは後で書くことにします。
以上。
あ、次は宜保さんに書いてもらいたいです(^^)

UML (ユースケース図) アドベントカレンダー (7日目)

こんにちは。 安里悠矢@長田研(仮)B4です。
内容は、前回の続きということで、ユースケース図について書きたいと思います。

———————————————————-

もしあなたがシステムを何も無い状態から作っていく場合、何から始めますか?
誰がシステムを使うのか、どの機能が必要かなどを検討するなど、要求分析をする必要がありますよね。
ユースケース図では、今から作成するシステムで実現すべきことを明確にするために用いられます。

ユースケース図

ユースケースとは、今から作成するシステムで実現すべきことです。ユースケースの表記方法は複数ありますが、一番左の楕円の中にユースケース名を配置する方法が一般的でしょう。

上の図は、システムがアクターに対して「データを登録する」という機能/振る舞いを提供することを意味します。

アクター

アクターは、作るシステムの利用者のことです。棒人間みたいな図で記述されます。
利用者といっても、人だけじゃなくて、ハードウェアだったり外部システムといった人間以外の要素も含まれます。

ユースケースの包含 (include)
「包含(ほうがん)」は、複数のユースケースから共通利用されるユースケースとの間に存在する関係です。

例えば、データを登録や削除には、一度認証処理を行わないと行けないようなシステムがあるとします。
このシステムの場合、「本人認証を行う」ユースケースはどちらでも利用されるので、<<include>>を用いて記述します

ユースケースの拡張(extend)

条件付きで他のユースケースを利用する場合、<<extend>>を用いて表現します。

例えば、データを検索してる際に、ユーザがファイルへの出力を行う場合、<<extend>>を用いて、条件付きで記述します。

ユースケースの汎化

「ユースケースの汎化」は、一方が他方の機能を継承する関係を表現したものです。
例えば、「ユーザを検索する」というユースケースに、「IDで検索する」だったり、「キーワードで検索する」という方法があるとします。どちらも「ユーザを検索する」という共通の機能を持っています。
汎化は、個別機能を持つユースケース側から共通機能を持つユースケース側へ、白抜きの三角形がついた矢印を用いて表現します。

アクターの汎化
「アクターの汎化」もユースケースと同様に、一方が他方の機能を継承する関係を表したものです。
例えば、「社員」というアクターに、「使える社員」や「使えない社員」というアクターがあったとします。
どちらも「社員」なので、汎化関係にあると言えます。
基本的なことについてはこんなものかな….

ユースケース図を描くときのポイント

①分析中毒にならないようにする
最初から完全に分析できるものではないです。気楽にやりましょう。
②ユースケース名は動詞で表現する
内容の曖昧さを無くすために、「〜する」とか動詞を入れましょう。
③作成/読み込み/更新/削除のユースケースは、「管理する」でまとめる
ユースケースが増えすぎて、図が読みづらくなります。なので「管理する」でまとめちゃいましょう。
④詳細すぎないようにする
ユースケースは、あまり詳細に書く必要はないです、汎化のように抽象的に描いたほうがいいです。
今日はこんなところで終わります。
次回担当の際は、クラス図とかについて書こうかな。

CTF入門 その2 (長田研アドベントカレンダー6日目)

M1の太田です。
さて、いろいろあって今日は12月9日ですね。
5日目の記事は某Dの先輩が某hatenaに匿名ダイアリーしたらしいです。
バランスボールについての記事でした。探してみて下さい。

CTF入門 その2

前回書いたCTF入門ですが、あれはコンピュータ寄りな内容だったので、今回はもうちょっと入門らしいこと書こうと思います。

CTFについて、前回は「セキュリティ技術を競うイベント」みたいに書いていたと思います。
でもCTFはコンピュータに限ったものではなくて、単なるなぞなぞみたいな問題も多数出題されるんです。

例えば、前回紹介したFlaggersの問題にこういうものがあります。
「タイトルは?
978410353422
978410353423
978410353425」
出題元URL

暗号みたいな感じですね。
今回はこれを解いてみたいと思います。

解いてみる

この数字でぐぐってみるとISBNという単語に当たります。
ISBNというのは書籍を特定するための番号で、学科で言えば学籍番号みたいなものです。

この数字が意味するところは…ぐぐると一発で出るので、これは自分で調べてみてください。

ついでに、ISBNにもチェックディジットがあったりするようです。
パリティっぽいですね。

これだけでは…

というわけでもう1つ解いてみます。
次の問題は以下の内容です。
「$ command1 | command2
答えは “|” を英語(小文字)で表記したものです。」
出題元URL

これはちょっとCUI触っていれば分かる通りですね。

終わりに

1つ目の問題でわかる通りですが、必ずしもコンピュータ関連の問題ばかりというわけではなく、いろいろな幅広い知識が求められる事が分かると思います。
他にもいろいろ、なぞなぞな要素だったり、それにコンピュータの知識が絡んでくるため、頭の体操とかにも良いかもしれないですね。

解いているうちに変な知識が増えてきて、すごく楽しいです。
面白そうだと感じた方は是非、CTFにチャレンジしてみてください。

511室に遊びにきてくれたら、教えきれる部分は教えます。
では、次はUMLかCSSの続きか…。
途中まで書いてるらしいUMLでもお願いしますかね。

UML (長田研アドベントカレンダー4日目)

こんにちは。 安里悠矢@長田研(仮)B4です。

何を書くか結構迷ったんですが
自分がETロボコンに参加してたので、UMLについて書きたいと思います。



UML (Unified Modeling Language)とは?

簡単に言うと「プログラムの設計書」です。
1990年代の初めは、プログラムの設計書の表記法が統一されていなくて、複数の表記法が乱立していました。
複数の表記法が乱立していると、表記法について毎回勉強しないといけないし、プログラム作るのも大変だし…
ってことでUMLという統一された表記法が確立されました。



UMLってそんな大事?プログラム書けりゃいいじゃん!

自分も初めはそう思ってました。
UMLがなぜ必要なのか?
教科書見てみると大抵は以下のことが書いてある
  • システムに求められる要求の高度化と多様化
  • システムの大規模化と複雑化に対応するため
  • 関係者間でのコミュニケーションの難しさ
….うん?って感じですね。
いろいろな教科書を見てきましたが、もっと難しいこと書いてある教科書もありました。
実際、UMLとか使って仕事している人にはこの意味が分かるかもしれないけど、
勉強し始めの頃は何を言ってるかわかりませんでした(多分今でもよく分かってない)
少し話は変わりますが….
もし、あなたが誰かに自分の作ったシステム(アプリケーションとか、プログラムとか)をレビュー(評価)してもらいたいとき、どうしますか?

プログラムを見せる!

それもありでしょう。
相手がプログラムをバリバリ書ける人なら適切なレビューが貰えるかもしれません。
しかし、相手がそのプログラム言語についての理解が浅かった場合、適切なレビューを得られないでしょう。
もしかしたらレビューすら貰えないこともあるかもしれません。

UMLを見せる!

相手がそのプログラム言語について理解している必要はほとんどありません(理解してることにこしたことはないですが)。
表記法については多少理解している必要があることもありますが
UMLの表記法は意外と簡単なので、分からない人にもすぐ説明できるでしょう。
プログラムよりもレビューは得られやすい。
また、そのレビューしてもらいたいシステムが本当に動くものなのか。
一緒に考えてもらえるきっかけにもなります。



UMLがなぜ必要なのか?

一番はこういうことだと思っています。
プログラムをガッツリ書けない人とでも、システムの妥当性を一緒に検証できる(考える)場を得られるから必要だと感じています。
やっぱり動くものを作るプログラマーは偉いと思います(実際にシステムを作っているし)
ですが、UMLも書けてこそできるプログラマーになれるのではないかなと感じます。


実際にUML書いてレビューさせるとダメ出しが多いし
プログラムみたいに動くものではないから達成感もなかなか得られないし
心折れることのほうが多いかもしれませんが
やっぱり大事な気がします



今回は技術的なことは一切触れてませんが、次回からやっていこうと思います。