Category Archives: アドベントカレンダー

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

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

宜保 行平@M2です。

 

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

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

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

 

閑話休題

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

 

終りに

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

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

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

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

よろしくお願いします。

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



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

人間スペックを上げる10の技術(長田研アドベントカレンダー3日目)

おはようございます、許田重久@長田研M2です。
これまでブログを書くことを頑なに拒んできましたが、今回はそういうイベントらしいので乗っかり勢としては乗らざるを得ません。

ということで本題です。
色々迷いましたが、せっかくなのでちょっと趣向を変えた題材にしてみました。
これから書くことは主に思考方法の技術です。心です。目をつぶっていても磨くことができます。

1. 思考はスポーツだと思うべし

考えることはつらいことです。慣れている人や元々スポーツだと思っている人は別として四六時中頭を働かすことはつらいと思います。
しかし、慣れます!やればやるほど鍛えられます。
そして上手くいけば脳汁でます。

ちょっと考えて「もぅマヂ無理。リスカしょ・・・」って思う人は思考体力のない人です。
最初はそんなもんです。1分ですら無理でしょう。
めげずに毎日がんばりましょう(思考具体例はあとで)

効能:
時間が圧縮されます。知識が圧縮されます。思考スピードが圧縮されます。

※当たり前ですが一朝一夕でできるものではありません。

2. 感情のコントロールは技術

人間スペックを上げるには感情をコントロールすることが重要です。
感情のコントロールという言葉はあまりにもありきりたりで胡散臭いですが、自分の感情をコントロールすることは可能です。心の操作は技術です。訓練できます。
まわりを見ていると心の問題はどうにもならないと考えている人がすごく多いです。

さて、ではどうすればいいのか??
次に書きます。

3. 自分というロボットに搭乗する

初めは自分という身体(ロボット)に自分という意識(小人)が乗っかっていることをイメージします。脳にコックピットがあってそこで自分が身体を操縦していると思い込みます。
常日頃そういう状態であると想像しましょう。
想像するということが重要です。逆に言えばこれができないとアウトです。

想像した後、目の前にあるコップを右手で持ち上げろと指令を出してください。
コップを持ち上げることができたらいい具合です。

できなければ毎日1分ぐらい練習しましょう。

4. 自我との邂逅

コックピットに乗って待機していたはずが、自分が考えたくもないことをぺちゃくちゃぺちゃくちゃしゃべる野郎がいたるところからでてきましたね。
それが自我です。こいつらが諸悪の根源です。
こいつらは自分(という意識(小人))ではありません。

自我は何かとうるさいです。しゃべることを止めません。

2回言いますがこいつらは自分ではありません。
こいつらと折り合いをつけることが感情のコントロールです。

5. 自我との勝負

頑張ればこいつらをかき消すことができます。
そうそううまくできないと思います。ぶっちゃけ無理です。
この自我をかき消すことを瞑想といいます。
まあ、修行僧ではないので瞑想はいいです。上級者用です。

現段階では自我と小人がともに存在していれば問題無いです。
少なくとも自我を意識できている状態になることができれば勝ったも同然です。

また、自我があまりにもうるさい場合は小人の声を大きくしましょう。
現実世界と一緒で大抵、声の大きいほうが勝ちます。

6. ロボットの整備

実は最も重要です。
眠かったりお腹が空いていたりしたら勝てるものも勝てません。
今日はどうしても感情のコントロールができないというときにはさっさと寝ましょう。

7. 考え方のテンプレ作成

日常ではテンプレを作成しましょう。
アニメでもドラマでも対人でもなんでもいいです。常に考え方を拾い続けましょう。
そしてすぐに使いましょう。

あらゆる物事や人に一つのテンプレを当てはめるやからが多いですが、それは思考停止状態です。それぞれに最適なテンプレを考えましょう。また時間経過でもテンプレを変えていくようにしましょう。

8. テンプレとはアルゴリズム

テンプレの補足です。
例として新しい技術勉強に取り組むときのテンプレを考えてみます。

  • 30分きっかりやる。プラマイ1分のズレも許さない。
  • やったことはevernoteに適当に記述。
  • 何もわからなければまずは意味を抑える

みたいな感じです。これをテンプレAとして、技術勉強時のテンプレとして活用するとメリハリができて長続きします。
当然ですがテンプレが妥当でなければ適宜変えていきます。
思考訓練は柔軟性が大事です。

もう1個テンプレ例を上げておきます。
初めて会う人との接し方テンプレ

  • 開口一番に挨拶する
  • 名前や出身地、仕事を聞く
  • 取り敢えず終始ニヤニヤしとく
  • 相手の思惑を勝手に脳内で慮る

9. 妖精さんを呼び出す

上級者編です。
今、脳内には自我と小人がいます。
2人だと寂しいので住人を増やしましょう!
誰でもいいです。
が、やはりよく接している人や思い入れのあるキャラなんかを用いると良いです。
例:

  • 仮想比嘉(脳内で創りだした比嘉君と小人で会話させる)
  • 茉莉ちゃん(取り敢えず愛でる)
  • 悪魔と天使(自分をコピーした悪魔と天使)

これらのメンバーで脳内円卓会議をさせるとさらに面白くなるのでおすすめです。
効能は思考スピードが段違いで早くなります。

※自我を意識できない人がやると精神分裂症になるので注意

10. 思考訓練問題集

  • プログラミングや数学の問題
  • 単純に課題に対して答を探すでもいいですし、「そもそも微分積分って何に使うために考えられたの?」みたいなことでもいいです。

  • 一日の振り返り
  • 誰かと会話したのであればそのときの場面を思い浮かべてみます。
    あのとき比嘉君は何を思ってあんなことを言ったんだろうとかを思い返します。
    比嘉君の心を丸裸にする気持ちで考えましょう。

  • ルール決め、テンプレ作り
  • 自分が自覚している駄目な部分に対してテンプレ作りに励みます。
    コツは無理なく合理性のある、それでいて自分が心底嫌だとは思わない妥協点を探ることです。嫌なことは嫌です。でも変えられる部分は変えられます。

いかがでしたか。
長くなりましたが10のタイトルを脳内で咀嚼するだけで効果があるのではないでしょうか。
4ぐらいまでできるようになると社会に潰されることはないと思います。
また、これらを丸っと信じないで一考することをおすすめします。