2020-11-29

電算研会長を退職(退任)しました

はじめに
- 電算研とは
- 自己紹介
コロナ以前の電算研
コロナ禍の電算研
コロナを通して感じたこと
おわりに

はじめに

本エントリはコロナ禍で年間予定が狂った会長がどのように一年間研究会の運営をしたかを振り返るものです。駄文長文です。

電算研とは

電子計算機研究会の略称。

近畿大学の理工学部に所属する公認団体で理工学部所属のため理工学部生のみしか参加することのできないPC使ってなんやかんやしてる団体です。 Web開発やゲーム制作、Live2D、動画制作、イラスト、モデリング、競技プログラミングなど、多種多様な活動を行っています。

平時では、月に一度程度の部会と３か月に一度の活動報告会、近畿大学で開催される諸行事(学祭、OC等)以外はとくに制約もなく自由に各々が好きに創作活動をしていました。

部会では諸連絡や、大学内の諸行事のシフト決めなどをおこなっており、活動報告会での発表や行事での制作物展示を主たる目標としそれぞれが日々活動をしていたかと思います。

電算研に限った話ではないかと思いますが、PCを用いて制作を行うとはいえ活動のほとんどはオフラインで行っていました。そのため、コロナの影響により活動体勢を大きく変更せざるを得なくなりました。

自己紹介

近畿大学理工学部情報学科3年のものです、おとといまで(2019/12/2 ~ 2020/11/27)電算研の会長やってました。普段はいなたつと呼ばれてます。 WebとかVRに興味がある一介の大学生です。研究はブロックチェーンをやることになるかと思います。(予定は未定)

好きな言語はGolangです。万年金欠なのでエンジニアバイトをしたいなと思いながら一万年くらいたちました。

おわり。

コロナ以前の電算研

そのまた昔(僕が入部したころ)、電算研には班というシステムがあり、主な活動内容で3つくらいの班に分かれていました。しかし班長の人数に対し、班員の数(20人以上のところもあった)が多いため、それぞれの部員がどういった活動をしているのかの把握が難しくありました。そこで区分を細かくし、新たにチームとしてリーダーに対しメンバーが5人程度になるように組みなおしがなされました。

しかし、基本的には部員個々での活動を行っていました。

そこで複数人で一つの目標へと向かい活動をするためのプロジェクトという制度が9月ごろに制定されました。この制度のおかげでもともと個人で活動していた人が複数人で協力し一つのものを作ることができる環境ができました。

プロジェクトシステムにより、複数人でWebサービスの開発を学び、開発を行うプロジェクトや機械学習に関する書籍の輪読を行うプロジェクトなどが立ち上がり、部員間での知識や技術の共有が促進されたと感じています。

プロジェクト制度以前は、不定期で勉強会という形で知識や技術を先輩から後輩へ共有されることもありましたが、まれなケースであり、知識や技術といった資産の継承が積極的になされていたとは言えなかったと思います。また、部員同士で一緒に同じ書籍を読み進めるといったこともなかったかと思います。

コロナ禍の電算研

僕が会長をしている期間ですね。

すべての予定が狂いました。プロジェクトシステムの強化や、3Dプリンタを購入し電子工作やモデリングした作品の物理展示などいろいろ計画をしていましたが、すべてが崩れ去りました。そのため、思い描いていた一年とは全く違う一年にはなりましたが、オフラインで活動していたところから完全オンラインへと移行することや、前代未聞の新入生勧誘など特に前者に関しては電算研の会長は前にも後ろにもいれど僕(コロナが出た年の会長)しかできなかった貴重な体験ができたともポジティブになれば考えられます。実際貴重な体験ができたと思っています。

オンライン活動をするにあたって導入したツールや施策について書いていきます。

部内Discordサーバーの設置

コロナ以前の電算研ではSlackを導入していました。しかしオンラインで活動するには、複数人での通話や画面共有を行う場面がでてくることが考えられるため、公式的にDiscordをSlackと併用することにしました。もともと自分がリーダーをしていたプロジェクトでは、コロナとは関係なく冬期休暇の期間からオンラインとオフラインの両方で活動を行っていたため、スムーズに導入ができたと思います。以前は、部室にいけば部員と話すことができ、刺激をもらうことができましたが、オンラインでは部員間が気軽に会話をすることができないため、Discordにオンライン部室を設置し、雑談をしながら作業をできる空間を公式に作成しました。

また、電算botというDiscordのbotを作成しました。このbotには、Discordのロール管理や、VC(オンライン部室)への入室をSlackへと通知する機能などがあります。

反省としては、オンライン部室を設置し、Discordを使用した交流イベントなどを開催したりしても、オンライン部室へと足を運ぶ人はあまり増えませんでした。特に新入生がオンライン部室へと足を運びやすくしようと企画を立てたりしましたが、企画時以外にもオンライン部室に人が来る空間を作れなかったところが悔やまれます。

オンライン部室とは別にプロジェクトのVCは使用されているため、活動外に部室に行って居た人と雑談をするのとわざわざVCに雑談をしにいくことにはいくらか壁があるのだなと感じました。

オンラインでの活動となったため、プロジェクトでVCを活用し、画面共有をしながら活動するシーンが本年度のプロジェクト活動の主たるものでした。

ここでオフラインとの差を感じた点は、先輩が講師、後輩が生徒のような形になる際、後輩のPCでうまく動作しなかった際など、オフラインでは先輩が操作をすることができたため、トラブルシューティングが容易でした。しかしオンラインだと画面を見ることはできても直接操作はできないため、特に始めたばかりの新入生に教える際に用語の語彙の差などが大きいため、トラブルシューティングする際に操作を伝えることが難しかったです。

しかし、ゲーム開発などの活動ではそれぞれが家のデスクトップＰＣを使うことができるため、部室の限られたPCを複数人でモブプロのような形で使う必要がなくなる点などは良かったです。

progressシステム

部室にいけば誰かが作業をしていてほかの人がどんな活動をしているかがざっくりとわかりましたが、オンラインベースでの活動となると、電算研では3か月に一度の活動報告でしかほかの部員の活動を知ることができなくなってしまうため、偶数週の週末に最近の活動を簡単に報告するprogressというシステムを作りました。

結果から言ってこの施策は失敗でした。

部員の中には経過の進捗を可能な限り隠し、活動報告会で披露したいと考えている部員もいました。そういった部員は報告をするためのダミー進捗を生むことになってしまったり、そもそも強制力も微妙なためはじめは毎回やってくれていた人も次第に頻度が下がったり、投稿しなくなったりしていきました。

なにより言い出した手前投稿する人が減っても自分だけは一度も欠かさずやらねばならないという使命感がメンタル的にきつかったです。

部員の活動のペースやモチベーションは人によってさまざまなので全体での小スパンでの報告義務は厳しいものがありました。

ここの改善は期待といったところです。。。(progressから解放してくれ)

オンライン入部説明会

近畿大学ではコロナとは関係なく全学でSlackの導入が決定されており、僕が通う情報学科では一足早く導入がなされていました。そのおかげもあり、SlackとTwitterを活用した広報活動と、全4回の説明会と、DMでの説明会アーカイブの配布をすることで20名程度の新入部員の獲得が出来ました。他団体では新入部員が居ないところも多く、オンラインでの広報活動は成功したと思っています。なんなら僕の代の入部者より多い気がします。オンラインでの説明会にはZoomを用いました。活動の形式に関する説明をスライドを用いて説明を行い、数人の部員に活動報告を行ってもらいました。活動報告を加えたことにより硬い説明だけでなく、実際にどんなものを作っているのか、どんな人が部にいるのかを紹介出来たかと思います。

また、この期間中に部員以外でも参加できる勉強会を開催しました、SlackもしくはTwitterで勉強会へ参加したい旨連絡をすればZoomのリンクを返信する形で勉強会を開催しました。これによって電算研にはいったらこんなメリットがあるんだといったものを提示できたのではないかと思います。

オンライン交流会

主にdiscordを使用し不定期で交流イベントを開催していました。イベント企画班というものが電算研にはあり、平時は長期休暇にハッカソンを開催したり、新歓イベントを開催したりしていました。今年はイベント企画班主導でdiscordによるVCを用いて対話形式のゲーム(ウミガメのスープ、ワードウルフ等)を不定期で行っていたりしました。それに加え、僕主導でビブリオバトルのような形式で与えられたテーマで好きな物を宣伝し誰の発表が1番魅力に感じたかを競うイベントを11月に週に一回開催しました。

このイベントの狙いとしては、オンラインとなりLT会などを開催できておらず、発表機会がとても減っていることを危惧しており新入生でも発表できる機会を作ろうとしました。結果的には発表者はよく見るメンツが多かった部分もありますが、普段積極的に発表していなかった部員も発表してくれたりし、一定の効果は見込めたかと思います。

第1回は漫画がテーマでした。意外とネタバレをしないように喋るのが難しく初回だったこともあり発表者も少なかったです。結構グダリました。準備不足スンマセン。

第2回は、音楽というテーマで、好きなバンドやアーティストを宣伝してくれる人がいたり、作曲者を宣伝してくれる人がいたり、Spotifyはいいぞって話をしてくれる人がいたりたような解釈がありとても面白かったです。幸い音楽性の違いで解散することにはなりませんでした。

第3回は一風変わったテーマで買ってよかったものというテーマでやりました。このテーマは結構良かったと思っていて、僕個人としては、買おうと思っていたもののレビューを聞けたりして良かったです。最近買った地酒の話や美味しい紅茶の話をしてくれたり、HHKBの話をしてくれる人がいました。僕は2000円くらいで買った格安ゲーミングキーボードがクオリティ高くて良かったって話をしました。コスパすごいです。 discordに普段顔を出さない人も参加してくれたので結構嬉しかったですね、何かしらの形で発表機会を確保してって欲しいです。

オンラインハッカソン

テーマ決めから審査員(顧問の先生)への依頼、メンター、審査員、公式Twitterへの投稿まで全て1人でやりました。地獄でした。一人でやるもんじゃねぇ。。。

ハッカソンのテーマは「和」でした。各チーム色々な読み方、解釈をしてくれました。発表会はzoomを使用し、それ以外は主にdiscordを用いて行いました。初日のアイスブレイク等もdiscord上で行いました。これはdiscordのVCへと参加する心理ハードルを下げるために少々無理やりにでもdiscordを使いたかったのでdiscordを使いました。zoomのbreak○utr○○mのような機能を作成したのですが当日に終了時に全参加者をミュートする機能を追加しようとしてawaitを書き忘れるとかいう初歩的なミスでバグらせてしまい、手作業でグループ分けを行いグダってしまい申し訳なかったです… アイスブレイクは5人グループで15分で4つのテーマで好きなものを交えて自己紹介をするといった内容を3回別々のグループで行いました。その後、テーマ発表を行い、グループ分けを行いアイデア出しを30分行い、さらにもう一度グループ分けを行った時点のグループを最終的な開発チームとし、アイデア出しを行いました。

アイスブレイクでは色々な部員と話すことができ、良かったと思いますが、5人グループ15分は少々短かったです。30分とかの方がいいかもしれないと感じました。アイデア出しを2回行ったのは、テーマの「和」は色々な読み方ができ、多様な解釈が出来るため、色々なアイデアを共有できるようにしたかったため2回行いました。そのおかげもあってか、色々なアイデアが聞けて面白かったです。個人的には、「和」→ 和了(あがり)って読んでいたのが想定外で面白かったです。和→キメラとかも面白かったですね。

オンライン勉強会

オフラインで行われていた勉強会をZoomを用いて行いました。アーカイブを残せるため日程が合わなかった人も勉強会でした内容がわかるため良かったと思います。

欲を言うならもうちょっと開催されてほしかった。講師側をやりたいと思える雰囲気をもとから作れていなかったのが原因ですかね。(とても難しい)

classシステム

オンライン勉強会に加え、新入生それぞれの興味のある分野をアンケートを取り、人員を割り振り少人数でサポートを行うシステムです。

良かった点としては、興味が一定ある人にスポットを当てて教えることができる点と、講師側にある程度の裁量があったため人数や進度に合わせてそれぞれのclassがある程度自由に行えた点です。

良くなかった点は、多対多で割り振ったため、進行がしにくかった点と、最低限度の達成目標の設定などをせずに、各classに裁量を与えてしまったため、ほぼ機能していないケースも見られた点です。また、classによっては、その役割をprojectで賄えている部分もありました。projectとの兼ね合いは特にもう少しうまくできたかと思います。

できることなら一対一で行えればよかったのですが、講師側の人数の問題や、講師側のやってきたことと新入生のやりたいことを一対一でマッチさせれなかった際の対応等が急なつけ焼き刃ではできそうもなく多対多でclassシステムを行ったのですが、うまく行ったclassといかなかったclassが見受けられました。

理想論ではありますが、マッチングを講師側の経験・知識に関係なく一対一で割り振り、ともに学ぶことができればいいのですが、それをするにはもう少し準備期間が必要だっただろうなと思います。

プロジェクト強化

既にあったプロジェクトシステムですが、運用に関してのルールがなかったため、プロジェクト活動指針というものを制定し、プロジェクト活動に当たってのリーダーの権利、参加者の権利を明確にし、活動報告ではプロジェクト単位での活動報告と個人での活動報告を分離しました。プロジェクトに参加していない部員全員とプロジェクト参加者で個人活動の活動報告を希望するものが個人活動報告会にて報告を行い、プロジェクト活動報告会では全てのプロジェクトが活動報告を行うと言った形にしました。初めは、個人活動報告を免れるためにプロジェクトに入っているのでは無いかと感じた部分もあったため活動指針にプロジェクトからの除名権限をリーダーに与え、参加者の権利とし、異議申し立てをする権利を与えました。この権利の行使は役員への報告義務があり、異議申し立てがあった際、リーダーと参加者と役員の三者で話し合う場を設けられるようにしました。幸いこの1年間でこの話し合いが行われることも無く問題のない運用ができたかと思います。

wikiの導入

これは僕主導で導入した訳では無いですが、運用をしてたので軽く。 projectの作成時の申請などをwikiにテンプレートを作成し全部員が確認できるようにしました。また、projectパス以下はprojectのメンバー、活動内容等を書くページ以外は各projectに裁量があったため、議事録を作成しているprojectも見受けられ、参加者以外でもどのような活動をしているのかがある程度わかるため良かったかと思います。

引き継ぎ資料も、それぞれの役職者間で行っていた物を、文書データをwiki管理するようにしました。他にもGoogleDriveを使用しているものもあるため完全移行とは行きませんが、文書データとしてwikiに残すことで前任者より前の引き継ぎも参考にすることが出来るようになる効果が見込まれると考えています。

オンライン勉強会の議事録ページに限定公開している動画アーカイブなどもwikiからアクセスできるようにしました。動画として残しやすい点はオンラインのメリットですね。

コロナを通して感じたこと

コロナ許さん

僕は、会長をする以前は一年間イベント企画班のリーダーとして活動をしてました。そのときからのテーマとして発表機会を多くしたいという思いがありました。コロナを通してというか僕がイベント企画や会長をするにあたっての目標が、発表しやすい空気・発表にレスポンスが来る空気を作りたいという思いがあります。発表というのは、資料を使ってしゃべるというのはもちろんテキストベースのものも含んでいて、開いたイベントはLT会やディベート会、アドカレなど自分の言葉、文章を発する機会をできる限りこの2年間で設けてきました。

ここで、コロナでも気軽に発信とフィードバックができるようにしたくprogressなどの施策を打ったのですが、全員やって下さいと言ってはいるものの、強制力もないため、やらない人は一回もやってくれませんし、はじめはやってくれていた人も周りがやらないためだんだんやらなくなってしまい、狙いであった、発表の機会の作成とモチベーションの喚起ができなかったのが悔しかったです。

オンラインでもほかの部員の状況が透けると刺激を受けること、与えることができると思いますし、フィードバックがあるとうれしいですし、モチベーションも上がると思うのですが、そういった雰囲気は一朝一夕で醸成できるものではないので難しい問題ではあると思います。

僕が会長の間はそういった施策については自分が欠かさずに続け、背中を見せ続ける(見てくれるとは言ってない)という選択をしましたが、強制力を持たせるという選択肢もあり、これは管理コストがかかるという問題もありますが有効な手の一つではあると感じました。

オフラインの活動ができないため、モチベーションがない人へアクションを届けることがとても難しく、モチベーションのある人のエンジンをいかに切らさないかがとても重要ではないかと感じました。

このモチベーションのある、あった人のエンジンを切らさないことがとても大切なのですが、全体へこれをしてくださいといったタスクを与えると、もともとモチベーションあった人のモチベーションを削ってしまう可能性もあり、注意が必要であると今では感じます。

モチベーションのない人へアクションをすることはそもそもオフラインでも難しいと思うのですが、オンライン活動となった今、モチベーションのある人、ない人両方へアクションをかけようとするのは傲慢だったかもしれないです。もう一回この一年をやり直すなら僕はモチベーションがある人に全力投球をすると思います。自分の背中を見せるのではなく、モチベーションある人の背中を見せつけたほうが(背中の数が多いので)実際には効果が見込めたかもしれないなとも今では思ったりもします。

コロナ許さん

おわりに

やり残したこともありますが、一年間会長を務めさせていただけてとても良い経験になりました。環境が一変し、至らない部分も多く部員には多くの負担をかけてしまった部分もあったかと思います。うまくいかなかった部分もうまくいった部分もありましたがすべて協力してくれた部員みんなのおかげです。ありがとうございました。

新会長がうまくいかなかった点等改善していってくれると思うので、協力して電算研をよりよくしてってください。おわり。。

2020-01-11

HaskellでABCを攻略していく ~ABC003C~

問題はこれ ABC003C

リストと数を入力し、ゴニョゴニョ計算した結果の最大を求める問題ですね。

入力

動画講座の総数 : _
見ることができる動画の数 : k
動画配信者のレートのリスト : rs

出力

達成できる最大レート

実装

0からスタートしてk回自分と動画配信者との平均を取り最大値を求める

ソースコード

import Data.List (sort)

main :: IO ()
main = do
    [_, k] <- map read . words <$> getLine
    rs <- map read . words <$> getLine
    print $ ans rs k
ans :: [Double] -> Int -> Double
ans rs k     =
    let l    = length rs
        list = drop (l - k) $ sort rs
        in calc list

calc :: [Double] -> Double
calc list = foldl (\ a b -> (a + b) / 2) 0.0 list

関数

ans関数

答えを返却するための関数

ans :: [Double] -> Int -> Double
ans rs k     =
    let l    = length rs
        list = drop (l - k) $ sort rs
        in calc list

Double型のリストとInt型の値を受け取り、Doubleで本問題の回答を返却する。 let式ではリストの要素数を表す変数 l と視聴する動画配信者のレートを表すリスト list の二つを作成し、calc関数の結果を返却する。

import Data.List (sort)でsort関数をimportし、引数のrsを整列する。 drop (l - k) りすとの形になり、drop関数にて、先頭から(l - k)要素をリストから削除する。最終的には要素数 k で整列されたリストができる。

calc関数

答えを計算する関数

calc :: [Double] -> Double
calc list = foldl (\ a b -> (a + b) / 2) 0.0 list

calc関数は整列したDouble型リストが送られてくる。 (\ a b -> (a + b) / 2)ラムダ式を使い2値の平均を求めている。以降 f と表す。 foldl f 0.0 listでは、引数で与えられたリストを初期値0.0で関数fを畳み込んでいる。リストは昇順になっているため、小さい値から順に関数fに適用される。

2020-01-04

HaskellでABCを攻略していく ~ABC002C~

問題はこれ ABC002C

三点の座標から三角形の面積を求める問題ですね。

入力

aのx座標 : xa
aのy座標 : ya
bのx座標 : xb
bのy座標 : yb
cのx座標 : xc
cのy座標 : yc

出力

a,b,cで囲まれる三角形の面積

実装

一点を原点と考えた相対的な座標で面積を計算する

ソースコード

main :: IO ()
main = do
    [xa, ya, xb, yb, xc, yc] <- map read . words <$> getLine
    print $ abs $ ((xb - xa) * (yc - ya) - (xc - xa) * (yb - ya)) / 2

各入力を受け、それぞれ束縛し、計算結果を出力する

aを原点と考えるためにそれぞれの座標からxaまたはyaを減算する。

before (xa, ya), (xb, yb), (xc, yc)

after (0, 0), (xb - xa, yb - ya), (xc - xa, yc - ya)

(0, 0), (a, b), (c, d)のとき計算式は$|ad - bc|/2$なので $|(xb - xa)(yb - ya) - (xc -xa)(yc - ya)|/2$となるこの計算結果が本問題の出力値である。

2020-01-02

HaskellでABCを攻略していく ~ABC001C~

問題はこれ ABC001C

風向と風力を入力し、値に応じて風向と風力をレベルに分けて表示する問題ですね。

入力

風向 (0 ~ 3600) : Deg
風力 (0 ~ 12000) : Dis

出力

風向 (1 ~ 3文字の文字列)
風力 (1 ~ 12)

実装

レギュラーパターン

風力をレベルに変換
風向を16方位に変換
合わせて表示

イレギュラーパターン

風力レベルが0の場合は風向はCになる
ソースコード

windPower :: Int -> Int
windPower dis
    | d < 250   = 0
    | d < 1550  = 1
    | d < 3350  = 2
    | d < 5450  = 3
    | d < 7950  = 4
    | d < 10750 = 5
    | d < 13850 = 6
    | d < 17150 = 7
    | d < 20750 = 8
    | d < 24450 = 9
    | d < 28450 = 10
    | d < 32650 = 11
    | otherwise   = 12
    where
        d  = dis * 1000 `div` 60

windDir :: Int -> Int -> String
windDir deg wp
    | wp == 0   = "C"
    | otherwise = dir deg

dir :: Int -> String
dir deg = 
    let i = length (filter (< deg * 10) [1125,3375..34875])
    in ["N", "NNE", "NE", "ENE", "E",
        "ESE", "SE", "SSE", "S", "SSW",
        "SW", "WSW", "W", "WNW", "NW",
        "NNW", "N"] !! i

ans :: Int -> Int -> String
ans deg dis = 
    let wp  = windPower dis
        dir = windDir deg wp
    in dir ++ " " ++ show wp

main :: IO ()
main = do
    [deg,dis] <- map read . words <$> getLine
    putStrLn $ ans deg dis

関数

windowPower関数

風力を受け取り風力レベルに変換する関数

windPower :: Int -> Int
windPower dis
    | d < 250     = 0
    | d < 1550    = 1
    | d < 3350    = 2
    | d < 5450    = 3
    | d < 7950    = 4
    | d < 10750   = 5
    | d < 13850   = 6
    | d < 17150   = 7
    | d < 20750   = 8
    | d < 24450   = 9
    | d < 28450   = 10
    | d < 32650   = 11
    | otherwise   = 12
    where
        d  = dis * 1000 `div` 60

整数(風力 m / min)を受け取り整数(風力レベル)を返す where句では仮引数として受け取ったdisを1000倍した値を60で割った商をd(秒速)とし、dの値でパターンマッチングを行っている。

パターンマッチングではdとビューフォート風力階級の各階級の上限値を1000倍した値との比較いにより風力のレベルを返却するようにしている。

値が小数になり読みにくいため両方の値を1000倍した(100倍でよかった説)

通常0.2m/secは1000倍すると200になるが、50を加算することで小数第二位での四捨五入に対応している。

windDir関数

風向を決定する関数(風力の有無を判定)

windDir :: Int -> Int -> String
windDir deg wp
    | wp == 0   = "C"
    | otherwise = dir deg

風向と風力を整数値で受け取り、16方位+中央の方向を文字列として返却する。風力が0の場合は風向はCとなり、それ以外の場合は仮引数degを実引数としdir関数を実行する

dir関数

風向を決定する関数(風向の決定)

dir :: Int -> String
dir deg = 
    let i = length (filter (< deg * 10) [1125,3375..34875])
    in ["N", "NNE", "NE", "ENE", "E",
        "ESE", "SE", "SSE", "S", "SSW",
        "SW", "WSW", "W", "WNW", "NW",
        "NNW", "N"] !! i

本問題の入力は0~3600であるが、風向は小数点第二位までを確認するため、10倍し0~36000の値に変換することで、整数値で処理している。そして、値を順にfilter関数で評価し、境界を探す。境界を超えるとそこで方角が判明するので、そのindexの番号を用いて方角の文字列を表す配列のindex番号として使用し、方角を返却する。

ans関数

本問題での出力値を文字列として返却する関数

ans :: Int -> Int -> String
ans deg dis = 
    let wp  = windPower dis
        dir = windDir deg wp
    in dir ++ " " ++ show wp

wpは風力で、関数windPowerの戻り値 dirは風向で、関数windDirの戻り値

main関数

実行部分です。

main :: IO ()
main = do
    [deg,dis] <- map read . words <$> getLine
    putStrLn $ ans deg dis

[deg,dis] <- map read . words <$> getLine

をさらに分解

getLineは一行の入力を受け付けます。受け取った文字列を <$> (fmap) を用いてwords関数に適用します。 words関数はスペース区切りの文字列をリストにして返却する関数です。

ここで[deg,dis] <- map read . りすとって感じになります。入力した2つの数字を変換したリストに対してmap関数でreadを適用させ、二つの整数値にし、degとdisに値を束縛する。

2020-01-02

2020の抱負

あけおめです。

2020年はお絵かきとhaskell力を鍛えたいと思います。

今年の抱負は

アプリケーションを一つ完成させること
AtCoderの過去問をHaskellで書きはてぶろする
お絵かきいっぱいする
缶詰ゲームハッカソン
Qiita記事書く
一人アドカレ

今年も一年頑張りましょう。。。。

以上です。。。。

2019-10-31

初エントリ

はじめまして、関西の某大学に通ってる大学生園児nearです。

普段はweb系の開発を主にやっています。

ここでは技術記事にも満たない記録をつらつらと適当にポイ捨てしていこうとおもっています。

React,Golang,Haskell,TSあたりの記事を投げ捨てれたらなあと。。。