Takanoriのブログスマートフォン用の表示で見るTakanoriのブログこの広告は、90日以上更新していないブログに表示しています。本記事はストリームについて、Schemeを用いて説明しています。サンプルコードの動作確認を行ったSchemeの処理系、バージョンは以下のとおりです。x86_64-apple-darwin15.6.0ストリームデータ構造の観点からすると、ただのシーケンス代入やミュータブルなデータを用いることなく、状態を保持できます遅延評価を用いることで、無限を扱えます遅延リスト遅延リストとは構成時ではなく、選択時に実行されるリスト上記のみだと説明不足すぎるので、一般的なシーケンスのリストの問題点から説明します。シーケンスをリストで表現すると、状態がスタックとして積まれ続けるので、計算速度、メモリの使用量的に問題があります。以下のコードはn番目のフィボナッチ数を求めるものです。完全にリストが作成されるまで値は求まりません。processで書き直したものが以下のようになります。countを格納する場所さえ確保すればよくなりますが、シーケンスとして扱うことはできなくなります。processの両方の問題点を解決するためにストリームを用います。ストリームだと遅延評価を用いるため、リストとしてシーケンスを扱うコストを払う必要がなくなります。以下のようにcons-streamという構成子があるとします。<b>)<b>を評価するタイミングをリスト構成時ではなく、<b>を選択するタイミングに変更します。processでフィボナッチ数を計算する際の計算速度、メモリの使用量などの問題が解決されます。以下のコードでストリームを作成します。<b>)の<b>はstream-cdrでアクセスされてはじめて実行されます。result))))ストリームの動きでは、実際にストリームの動きを見ていきましょう。いくつか関数を簡単に説明をします。(newline))ストリームを構成したタイミングではリストの1番目のみ評価されます。リストの残りは呼ばれるまで、実行されません。7)67#<undef>無限のストリームストリームは無限を定義できます。フィボナッチ数列(フィボナッチ数の無限のストリーム)を定義すると、以下のようになります。b))の部分は呼ばれるまでは実行されないので問題ありません。10)55ストリームの加算ストリーム同士の加算も容易にできます。以下のコードはストリーム同士をを加算する方法でフィボナッチ数列を定義しています。Tumblr広告を非表示にするもっと読むコメントを書く2017-04-17仕事以外のコードを書き続けて半年経過してた仕事以外でもコード書くようになって約半年経過した。去年の年末の3日間以外は継続して書いた。github.comやったこと静的型付け言語に触れるGoRustC基本的なアルゴリズムとデータ構造を作るインタプリタを作るSICPの問題を解くオープンソースのプロジェクトへパッチを送るやった内容は上記のとおり、コンピューターサイエンスの基礎的な内容が中心だ。自分は情報系の学部ではなかったので、コンピューターサイエンスの基礎が足りてないことを自覚していた。RailsやJSフレームワークのAPIとか流行りのツールの使い方をたくさん覚えたりしても、基礎を疎かにしたままだといつか成長が頭打ちになるのではないか、という不安があった。このまま継続していけば、ある程度不安は軽減できそうだし、なによりコンピューターサイエンスは楽しいものだとわかった。半年間やってみたところで、プログラミング能力が飛躍的に上がったりはしないが、プログラミング全般的なことでなんとなくわかったような気になっていることもある。下記はプログラミング自体を始めて1年半くらいのやつが書いているので、間違ってるかもしれない。ググったり、リファレンスを見たりしない方が速く書ける単に調べるのに時間がかかるのではなく、書くというコンテキストから調べるというコンテキストに切り替えるのにコストがかかる。できるだけたくさんのことを覚えておいて、ガシガシと書き続ける方が集中を持続でき、速く問題を解決できる。コピペしてもいい本を読んだり、コードを見てもわからないときは、コードをそのままコピペする。コピペした後、コードを書き換えて試行錯誤しながらコードを理解する。最終的に理解し、自分のものになったのであれば、いいような気がする。他にもわかったような気になっていることはあるが、今度書く。最後に「難易度の高いプログラムを書く」、「仕事がめちゃ速い」みたいなことは、「単に知ってる」、「以前に類似の経験をした」ことが起因する場合もあるので、今後も継続して勉強する。実際には頭のいい人が才能で圧倒することもあるが、自分には関係のないことである。GoRubyから他言語を呼んでみたGoとRustをライブラリ化してRubyから呼んだ。ベンチマークとしてフィボナッチ数列の40番目を求めている。きっかけRubyは書きやすいが、速くない。機械学習の人たちはPythonからCやFortranなど速い言語で実装されたライブラリを呼び、爆速で数値計算しているので、Rubyでも似たようなことができるのではないか。lib.goGoのビルド時に-buildmode=c-sharedオプションを渡すとライブラリとしてコンパイルでき、fib.soとfib.hが作成される。fibはただのコメントではない。書かないと上記のコマンドを実行してもfib.hが作成されない。}}Cargo.tomlに以下の内容を書く。--release上記コマンドを実行すると、target/release以下にlibfib.dylibが作成される。Rails久しぶりにチームで働くと、新鮮で結構楽しいことがわかった。言っても、完全に1人で仕事してた訳ではない。直近の案件での登場人物は主に3人。自分は設計したり、RubyとかPHPとかJavaScriptでコード書いてた。進捗に興味がある人とはプロジェクトマネージャーのことだが、ほとんどマネージしてくることはなかった。最終の納期に間に合いさえすれば、何一つ口出ししてこないタイプだった。*1毎日、「進捗に問題ないです。」とメールしていたので、結構自由にできた。デザイナーはマジでどこの誰かわからない。HTMLとCSSとimgのファイルをプロジェクトマネージャー経由で連携してもらっただけで、コミュニケーションをとったことがない。こんな感じだったから、ここ半年間くらいはチームで仕事してる感がまったくなかった。*2チームで働くことのいい点を挙げてみた。チームで働くとどう変わったか周りの人たちとコミュニケーションを取る他の人からフィードバックを受ける他の人が書いたコードを読む時間が増える周りの人たちコミュニケーションを取る話す時間が長くなるというより、こまめに意思疎通しようとするようになった。エンジニアの好きな非同期のコミュニケーションをとることが多い。requestsを使っている。詰まったとき、詳しい人にすぐ聞けてラッキー。あと、当たり前だけどバージョン管理システムを正しく使おうと思うようになった。コミットメッセージを他人が読んでもわかりやすいように書いたり、チームで決められたフローでブランチを切っていったりするようになった。他の人からフィードバックを受けるペアプロしたり、コードレビューしてもらったりするようになった。アジャイルだからチームで振り返る時間もたっぷり確保されている気がする。あと、ペアプロしてると他の人が開発している様子を見れて面白い。ターミナルとかエディタとかをすごくいじってて、「今、何やったんすか?」とか「何すかそれ?」みたいなことが多発した。他の人が書いたコードを読む時間が増える他の人が書いたコードを読むことは単純に勉強になる。「別にGitHubでオープンソース見ればいいでしょ」って感じになるかもしれないけど、「なぜ、現在コードに至ったのか」的なことをすぐに聞けたりするのでよい。RailsはじめてRuby関西という勉強会に参加しました。最初に私のRubyの経験を書いたあとにRuby関西の感想を書きます。Railsで約1ヶ月くらいかけてCMSを作りました。Rails』を必死に読みまくって、なんとかCMSを作りました。第2版』を少しずつ読んでます。Ruby関西の感想Ruby関西に初めて行くので、会場に行くまでは「話の内容を全然理解できなかったらどうしよう・・・」みたいな気持ちになっていましたが、発表内容を聞いてみると楽しめました。Injection)についてググッてました。DIの概要をふんわりと頭に入れていたので、DIの有用性とDIが並列処理に応用できることは理解できました。そもそも「どういうコードがテストしやすいか」を正確に理解できていないので、「DIでテストが容易になる」というところはあまり理解できませんでした。自分が仕事で使うにはまだ早い(使う必要もない)感じでしたが、勉強になりました。Rails「チャットアプリの作り方を説明して、デモンストレーション」という流れをNode.jsとElixirとRailsそれぞれで行っていて、わかりやすかったです。Qiitaに初学者でも理解できるくらい丁寧に書かれた記事があるので、非常にありがたいです。WebSocket自体についてもっと知らないとなぁという気持ちになりました。話が逸れますが、最近「Elixir」が話題になっているような気がします。PRESSとかで見かけます。Itoさんの回でした。今、勉強していることが一段落したら、関数型言語とか並列処理とかの勉強もしようと思ってます。(例外)エラーメッセージと例外について、おさらいできる初学者にとってありがたいやつでした。演習問題を解いている際、最初「何をすればいいの?」みたいな状態になりましたが、演習問題2までは説明を聞いて理解できました。演習問題はGithubにあります。あと、専門学校の人たちと話せたのが少し新鮮でした。若いうちに自分のやりたいことを明確にしてることはラッキーだと思います。*3自分が通ってた高校は大学に進学する人ばっかりで、専門学校に進学する人はいなかったので、専門学校の人と話せて面白かったです。最後に今回、Ruby関西に初めて参加したわけですが、良い刺激になって良かったです。「勉強会に行く」とか「人に会う」とか「仕事で困難にぶつかる」などの刺激が継続的な学習に繋がるのではないかと考えています。これからはちょくちょく勉強会参加していきます。Tumblr広告を非表示にするもっと読むコメントを書く2015-10-07『チーム力をひき出すアジャイル開発』に参加してきたアジャイル今日は会社の人と『チーム力をひき出すアジャイル開発』というセミナーに参加してきました。その内容をまとめます。不要な訳でなく、比較したときに優先度は低いだけです。Developmentに書いてあります。上記の考え方に則していれば、アジャイルです。お客様のビジネス価値を最大化するためにアジャイルという「考え方」や「姿勢」を用いるのであって、「とりあえずアジャイル開発をしてみたい」みたいな考えは目的と手段の逆転現象が起きているんだろうなぁと考えています。チーム全員が何のためにアジャイル開発を取り入れているかを正しく認識できていないと、スクラムとかXPを実践しても効果が薄いみたいです。明日から取り入れられそうなアジャイル「契約形態的にアジャイルとか無理!」な方々もいると思いますが、こっちが勝手に取り入れられそうなやつがありました。KPTと呼ばれるチームでの振り返りです。K:Keep(良かったこと、うまくいったこと)P:Problem(問題点や課題)T:Try(改善したいこと、次に実施したいこと)コツはKから初めてポジティブな気持ちになることです。週に1回くらいなら余裕で続けられます。他にはお客様の品質保証の基準の中にアジャイル開発の手法を埋め込んでいくという荒業もあるそうです。いえ、アジャイルは一括請負と相性が悪い場合が多いそうなので、自社開発とか1ヶ月から3ヶ月くらいの契約と相性が良さそうです。自分が圧倒的に若く、30歳半ばから自分の父親くらいの層がほどんどだったので新鮮でした(?)講師に質問している内容や話してみた感じから判断すると、アジャイルでの開発がうまくいってないからセミナーに参加しているのではなく、これからアジャイルを取り入れたいと考えている人たちが多い印象でした。RailsRailsのプロジェクトを作成したら、次はまず、generateコマンドを使ってコードを生成することが多いと思います。◯◯のところがscaffoldだったら、MVCそれぞれのコード、migrationファイルなどが生成されます。大量に生成されるので、◯◯の部分がmodelの場合、controllerの場合、何が生成されるがRails初心者にとってわかりにくいです。うっかり不要なものまで生成していまいました。content:textこんなにも生成できます。書籍やインターネットの記事を読みながらアプリ作っている時はサンプルにしたがっていれば何となくアプリができてしまいます。◯◯」の◯◯のところに何を入れればよいかで少し悩みます。主なgenarateコマンドを入力した場合、生成されるファイルをまとめました。コマンドは意味を正確に理解したうえで入力しなければならないと改めて実感しました。Tumblr広告を非表示にするもっと読むコメントを書く次のページプロフィールid:Takanori11社会人4年目です。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。