安定化間近！Rustのimpl Traitを今こそ理解する - 簡潔なQ
概要: impl Trait が安定化間近である。これはトレイトオブジェクトと似た用途を持つが、静的ディスパッチされSizedのまま使えるため効率的である。 impl Trait が安定化間近 Rustでは新規の機能はまずnightlyバージョンに「不安定機能 (unstable feature)」として取り入れられます。そこでの実験を経て、プログラミング言語Rustに半恒久的に導入してもよいと合意されたものだけが「安定化 (stabilize)」され、betaやstableバージョンのコンパイラでも使用できるようになります。 さて、現在 「impl Trait」と呼ばれる機能の安定化のめどがたったというアナウンスがありました。この機能は2016年夏ごろに実装され、長い間待ち望まれてきた目玉機能のひとつでしたが、ここにきてようやっと、という感じです。そこで、 impl Trait について
【t_wadaさんの講演】技術の学び方 - だいたい死んでる
2017/09/23にサポーターズコラボの和田さんの「【和田卓人氏特別講演】若手エンジニアに送る、"心構え"と"キャリア観"」の講演会に参加していました。 参加した経緯としては、友人からすすめられたのもあるのですが、最近テストを書くことが多くあり、調べた際にT和田さんの話が多く出ていたので興味を持ち参加することにしました。 講演を聞き和田さんがプログラマーとして生き続けるために必要なこととして「技術を学ぶことよりも、技術の学びかたを学ぶこと」がこの先プログラマーとして生きていく上で大切だと思ったのでまとめたいと思います。 今回の講演ではないですが、資料があったので参考までに以下に貼っておきます。 speakerdeck.com 技術の学び方を学ぶとは プログラミングの技術は小さなことから大きなことまで、毎日のように新しい技術が出て来る。そのため、出てきた技術をすべて学ぼうとすると、時間が足
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
「お金」についての本を大量に読んだら、同じことばっか書いてあるからまとめた！｜今日はヒトデ祭りだぞ！
最近金の事ばっか書きすぎ！ と怒られたヒトデです。こんばんは 確かに最近の投稿を見るとお金が並んでいますね。うーん、よくないね。このブログはというと雑記ブログですから。雑記って事は１つの話だけじゃなくて、色々な話を書くブログって事です。というわけで、今日はお金の話をしようと思います お金のことが色々と不安だったので、お金についての本をたくさん読んだのですが（投資系のもいれると20冊くらい！）そうすると大体 「まーーーーた、これ書いてあるよ！！」 という内容がいくつかあります そういった「いつもの」に遭遇すると、パラパラ読み飛ばして「損したなー」とか思ってたんですが、これって逆に考えると どの本にも書いてあるって事は、もしかして「本質」的な事なのでは？？ と思うようになりました というわけで、お金に関する本で「これいつも書いてあるわ―」という事をまとめてみます まとめると、やっぱり結構本質的
コードレビューの極意。それは「自分のことは棚に上げる」こと！！ - Qiita
はじめに：コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん！って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、コードを改善できるせっかくのチャンスが失われてしまいます。 「自分ができているかどうか」と「そのコードを改善すること」は、それぞれ別の問題です。 なので、レビューする人は自分のことを棚に上げてでも、コードの問題点を指摘する必要があります。 また、レビューされ
Ruby書いたことないけどRuby書いた人の講演に行った - みたぬメモ
【まつもとゆきひろ氏 特別講演】若手エンジニアの生存戦略 - connpassに参加してきました。若手エンジニアないしはエンジニアを目指す学生向けに、生存戦略を説く主旨の講演でした。まつもとゆきひろ氏とは、プログラミング言語・Rubyを作った人です。 全体的な内容はこちらのブログで非常にコンパクトに紹介されているのでご参照ください。 zuckey17.hatenablog.com 私のブログではまつもとゆきひろ氏もといMatz氏が語ったことを前半に紹介しつつ、後半に主観感想もまとめたいと思います。 ■生き残るには？ -死ななければいい。 「エンジニアの生存戦略、つまり生き残るには？」 その問いに「単純ながら、死ななければいい。」という皮切りでスタートした。 じゃあこの"死なない"ためにはどうするか。 そもそも生き残るとはどのような戦略を取ればいいのか？ Matz氏は「背景や環境など当然違う
Haskellerから見たElixir - てくのろじーたのしー
なぜこれを書いたか 誰かHaskellしか関数型を知らない僕にElixirの特徴(特にHaskellとどう違うか)を教えて欲しいです#elixir— Tatsuki@Vim (@ttk_vim) 2017年5月22日 テクノさん案件だ— Haskell (@aiya_000) 2017年5月22日 オッス！オラ、テクノ— techno_tanoC📕 (@techno_tanoC) 2017年5月22日 案件が回ってきたので書きます。時間がないので雑な説明になります。雑すぎて公開するか悩みましたが、せっかくなので公開しておきます。先に謝っておきますごめんなさい。 自己紹介 趣味でプログラミングをやっている(ruby, railsを2年ほど書いていたのは過去の話)人です。 現在の本業は薬学部生です。平日は実習で潰れるのでここ最近全くプログラミングをしていません。 関数型プログラミングが大好き
「構え、撃て、狙え！」さっさと動くものをつくって、小さく素早く失敗するして学ぼう
Photo credit: Dushan and Miae via Visual hunt / CC BY-SA今回は、前回紹介した『UNIXという考え方』の続きで、定理の一つのご紹介です。「初期から動くものをつくってフィードバックをもらって、軌道修正しながら、ゴール見つけて達成しましょう」は、アジャイルな開発でも指摘していますが、Unixの哲学でもその重要さが語られています。 定理3:できるだけ早く試作を作成する ソフトウェアを使って、誰向けに何の問題を解けばよいか、どう解けばよいか、予めはっきりと分かっているのであれば、わざわざトライアンドエラーで失敗しながら学ばなくても、一度立てた計画通りにものごとをすすめることができるでしょう。例えば半年間の開発の初期段階で仕様・設計を作成して固定し、実装・テストして完成させる計画を立てても実現できるはずです。 ところが、終盤に実際に動くものを見て
暮らしの情報サイトnanapiはサービスを終了いたしました | nanapi [ナナピ]
2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。 約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。 掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。 長きに渡りnanapiを応援してくださり、本当にありがとうございました。
![暮らしの情報サイトnanapiはサービスを終了いたしました | nanapi [ナナピ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/420112875c05dcaadf2a5dd3f98760dc35d7162b/height=288;version=1;width=512/https%3A%2F%2Fimage.nanapi.com%2Fr%2F2014%2F07%2F14%2F11%2F20140714113641_53c34239cea08.jpg)
「プログラムの書き方は知っているが、何をプログラムしていいか分からない」 | POSTD
新人の開発者が繰り返し突き当たるテーマがあります。プログラム言語を1～2種類勉強するのに時間を費やしたり、プログラミングの演習を行ったりすることに関して問題はないと感じていても、学んだことをどう応用していいのか分からずにいるのです。このことは、次のようなフレーズとしてよく耳にします。「プログラムの書き方は知っているが、何をプログラムしていいのか分からない」と。これに対する答えは、一般的に、「プログラミングの課題を行いなさい」、「オープンソースプロジェクトに貢献しなさい」、または、「ゲームを作りなさい」というようなものです。 プログラミングの課題を行うことは、知的ないい訓練にはなります。しかし新しいプログラムの開発方法を学ぶのにはあまり役立ちません。オープンソースプロジェクトに貢献するのは確かにステップアップになります。実際のプロジェクトがどのように構成されているか学び、プログラム言語の技術
今日から使える？飲み会参加者を聞き出して上手に欠席連絡する方法【森もり子】 - ぐるなび みんなのごはん
「飲み会しようよ！」と誘いの連絡が来たとき、あなたは何を想いますか？ そうですね。 「飲み会のメンバーは誰なのか」ってことですよね。 飲み会の楽しさは、「誰と飲むか」で大きく左右されます。 「あの人が来るなら行きたくないな……」なんてこともありますよね。 出来ることなら、メンバーを把握した上で、飲み会に行くかどうかを判断したいところです。 しかし、飲み会に誰が来るかを幹事に聞くのって結構勇気がいりますよね？ だって…… みたいになったら最悪です。 今日は「その飲み会、誰が来るの？」と上手く聞く方法について考えたいと思います。 「誰が来るの？」が聞きにくい理由 まず、上で述べている「誰が来るかを聞きにくい理由」を詳しく見ていきましょう。 仮に飲み会に誘われたあなたが幹事に「誰が来るの？」と聞き、飲み会のメンバーを教えてもらったとします。 この後、あなたは「行くor行かない」を返信することにな
アメリカの会社で三ヶ月仕事して必要だと思った英語力 - Jeffsuke is not a pen.
Rebuild.fmを聴いてて、まだ友人のポストを見て、自分も思うところがあったので、書いてみる。 3ヶ月前からアメリカのスタートアップで働き始めたてなので参考になると思う。 まず働く上で必要な英語力って 仕事をする上で必要な能力 同僚との日常会話 の2つ。 面接に通って、仕事を手に入れる上で、英語力という意味では「1.仕事をする上で必要な能力」があれば問題ない。 実際に働く上で痛感したのは「2.同僚との日常会話」の不足。 英語の四技能 どのレベルになっても基本的には以下の能力のどれを集中して伸ばすかという話になる。 リーディング リスニング ライティング スピーキング 1. 仕事をする上で必要な能力 これは、正確に物事を表現する能力を指している。具体的には、 正しく喋っている人や、正しい書き言葉を理解する能力 ロジカルに物事を英語で正確に説明する能力 技術力による文章理解 これはどれも書
私は、弾劾のプロセスとネットの性質に戦慄したんですよ - シロクマの屑籠
ネットの暗い情念が“世論”と接続してしまう怖さ - シロクマの屑籠 昨日の記事にいろんなコメントがはてなブックマークやtwitterで集まっているので、補足……というより、大事なことだと思うのでもう一度書きます。 断っておきますが、今回の佐野氏の件はグダグダ＆問題だらけにみえ、すでにエンブレム使用中止が決まった今だからあえてインターネット上に書くと、「こんな庶民感覚からズレて、胡散臭いデザインなど消えてしまえ」と私個人は思っていました。佐野氏の迎えた顛末は自業自得な部分を多く含み、結果として、大会運営者の姿勢にも疑義を突きつけるものになったとは思っています。この個人的感想は以下を説明する前振りとしてここに書きましたが、本件が騒動になっている間、オンライン上に吐露しないよう意識していました。 私はエンブレム中止や佐野氏自身に戦慄したのではなく、弾劾のプロセスとインターネットというメディアの特
「独学でプログラミングを勉強しても実務に通用しにくい理由」を読んだ感想 - 文系プログラマによるTIPSブログ
なんか難しく考え過ぎなんじゃないかな〜、と思ったり、思わなかったり。 こちらの記事を読みました。 主さんの意見としては以下のようですね。 １．独学では妥協をいくらでもできる ２．興味の範囲内のことしかやらない。 ３．自分の実力に合わせた実装しかしなくなる この意見への批判とかではないですが、私の見解では大分異なります。 treeが思う独学が実務に通用しにくい理由 何故通用するのか 皆どうやってプログラムを学んだのか 現場の人間はそんなに有能なのか ではプログラム以外で通用しにくい部分はあるか？ 雑感 treeが思う独学が実務に通用しにくい理由 通用しますよ。余裕で。 これでは話がこれで終わってしまうので、もう少し詳しく書きます。 何故通用するのか 皆どうやってプログラムを学んだのか 日本は他の教育先進国と違ってITはゴミ扱いされ、義務教育の間は実践で使えるレベルのIT教育は行われません。従
プログラミングよりも健康づくり？ Googleが社員に求める3大必須スキルとは - ログミー
IVS 2015 Springの本セッションの前に行われたインフィニティ・ベンチャーズLLP・小林雅氏とCampus for H・石川善樹氏による特別対談。書籍『最後のダイエット』を出版したCampus for H・石川氏は、オフィスワーカーの健康について、Googleの社員教育で実践されている、寝ること・体を動かすこと・料理することの3つの要素と仕事との関連性を解説。自然に健康になりながら、仕事のパフォーマンスを高める方法を紹介しました。 予防医学の一番のテーマは「オフィスワーカーの健康」 小林雅氏（以下、小林）：IVS特別番組、今回は……。 ジャン！ 『最後のダイエット』でございます。 今回『最後のダイエット』の著者である、石川善樹さんにお越しいただきました。よろしくお願いします。 石川善樹氏（以下、石川）：よろしくお願いします。 小林：僕が石川さんを知ったきっかけはですね、TEDxU
アインシュタイン以上のIQを持つ、自閉症の少年のスピーチ。「大切なのは学びじゃない」 | TABI LABO
学ぶことだけに集中して、「あること」をやめてしまっていませんか？ 13歳のジェイコブ・バーネットくんは、アインシュタイン以上のIQを持つ少年です。そして、彼には自閉症と戦っているという側面もあります。そんな彼が、過去の天才たちが「学ぶこと」よりも重視していた「考えること」の必要性について、Ted Conferenceで語りました。 ここでは、そのスピーチの内容を一部抜粋して紹介しましょう。 （記事下の動画では、スピーチのフルバージョンが視聴可能です） まず最初に、皆さんが伝えたいことあります。 宿題をやっていると想像してください。宿題とはやらなければいけないことです。うまくできれば良い成績をもらい、賞をもらうこともあります。でも、もしもそれが間違いだとしたら？つまり、すでにそこにあるものを受け入れるだけではなく、自分だけのユニークな視点で物事を見る必要があるしたら？ 「円」を例に話
お金がないと幸せになれないのか - phaの日記
AKBメンバーは結婚相手に“年収1,000万円”望む、正社員平均は442万円。 | Narinari.com 昨日放送されたフジテレビ系「僕らが考える夜」というAKBメンバーらが出演する番組で「最近の若者は働かない人が増えているのか？」「お金は幸せに必要なのか？」みたいなテーマで話したりしました。自分をテレビで見ると冷や汗出ますね……。まあなんとか番組としてまとまって放映されていて安心しました。 お金ねー。難しいですね。お金は生きていくには必要なものではあるけれど、でもそんなに一定以上いらないな（だからあまり働きたくない）と思うのも事実なんですよね。僕は金持ちになったことはないけどサラリーマンをやっていたときはあって、そのときは毎月十数万くらいの手取りだったんだけど、あんまりお金使わないので結構お金が余って貯金してたんですよね。だから「お金そんなにいらない、仕事だるい、仕事したくない」と思
情報共有ができないチームの人間関係は破綻する | サイボウズ式
【サイボウズ式編集部より】「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回は日野瑛太郎さんによる「情報共有ができないチームのもろさ」について。 チームで働く場合、情報共有はとても重要です。仮に情報共有を一切しないのだとしたら、それは一人で働いていることとほとんど何も変わりません。チームで情報が共有されることではじめて、他人を手伝ったり意見を言ったりすることができるようになります。情報共有はチームワークの基本中の基本だと言ってもよいでしょう。 しかし、そんな基本中の基本であるはずの情報共有が、あまりうまくできていないというチームを結構よく見かけます。人数が少ないうちはある程度うまくまわっていても、チームの人数が増えるにつれて情報共有がいい加減になってしまうということも少なくありません。 僕がまだ会社員をしていたころに一
エンジニアに「この会社はないわ」と思わせる面接のパターン - タオルケット体操
photo by DonkeyHotey 就職市場は売り手市場になりつつあるだとか、IT業界は人手不足だなどという話を最近はよく聞きます。 が、そういうわりにはマイナビだとかの斡旋サービスが出す雇う側視点の面接ガイドみたいなものが幅を利かせていて、雇われる側が面接の時にどういう基準で会社を選別しているのかみたいなおはなしは見かけない気がします。当たり前ですが、雇われる側にとっても面接とは擬似的にその会社の人間を体験する場（インターンほどではないですが……）なので、実際にやりとりをしてみたところで魅力に欠けるような会社であれば、志望を取り消します。逆お祈りメールです。 そんなわけで、プログラマーが面接を受けて「この会社こわ、入るのやめよ」っておもうような基準についてのお話ってみかけない気がしたので、エンジニア仲間と駄弁ってて出てきた話題だとか独断と偏見から出てきた考えだとかを書きなぐろうと思
プログラマが知るべき97のこと
プログラマが知るべき97のこと大人気の書籍『プログラマが知るべき97のこと』のエッセイを無料で公開中！すべてのプログラマにおすすめの本がウェブで読めるようになりました。 エッセイ一覧分別のある行動関数型プログラミングを学ぶことの重要性ユーザが何をするかを観察する（あなたはユーザではない）コーディング規約を自動化する美はシンプルさに宿るリファクタリングの際に注意すべきこと共有は慎重にボーイスカウト・ルール他人よりまず自分を疑うツールの選択は慎重にドメインの言葉を使ったコードコードは設計であるコードレイアウトの重要性コードレビューコードの論理的検証コメントについてのコメントコードに書けないことのみをコメントにする学び続ける姿勢誰にとっての「利便性」かすばやくデプロイ、こまめにデプロイ技術的例外とビジネス例外を明確に区別する1万時間の訓練ドメイン特化言語変更を恐れない見られて恥ず
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
