Rustは何が新しいのか（基本的な言語機能の紹介） - いもす研
Rust は、Firefox を開発する Mozilla が開発し、次世代ブラウザの開発に使っているプログラミング言語です。借用検査という概念を導入することによりメモリ安全およびデータ競合安全をコンパイラが保証する言語であり、2015年中頃の安定版のリリースあたりから次第に注目を集めるようになりました。 メモリ安全とは、メモリの範囲外アクセスや二重解放、ヌル参照、未初期化領域へのアクセスがない状態を表します。ただし、Rust の言うメモリ安全とは、メモリリークをしないことを保証するものではありません。 データ競合安全とは、あるひとつのオブジェクトに対しての読み込みおよび書き込みのが同時に起き結果が不定になる状態にならないことを表します。競合状態とは異なります。 無名関数という概念を様々な言語が次々と導入したように、プログラミング言語は相互に影響を及ぼし徐々に変化しています。Rust は「寿
GoのためのGo
Go言語はシンプルさを念頭にデザインされた言語です。仕様は単純明瞭さのために小さく収められていますが、そのため表現力に欠けているとか、コードが冗長になるという印象を持つ人も多いでしょう。有名なところでは、ジェネリクスや例外といった機能が（今のところ）存在しないことが問題にされることが多いようです。 一般に、ソフトウェアエンジニアリングというものは書かれる言語だけに依るものではありません。視点を拡げてGoを取りまくツール群を含めて見てみると、go fmt や goimports といったツールが広く使われていること、また go generate コマンドの存在などを見ても、Goという言語には、人間のプログラミングを機械によってさまざまな面から補助しようという態度があります。
C#でのnull参照問題への取り組み ― null参照問題（後編）
最近のC#ではnullの存在が大きな問題となっている。前回（前編）で説明したnullの事情を踏まえ、今回（後編）は、将来のC#がnullをどう取り扱っていくのかを見ていく。 ← 前回 連載 INDEX 次回 → 前編では、nullが存在する理由や、nullがあることで起こっている問題などについて説明してきた。 後編では、C#が具体的にどう課題に取り組んでいくかについて見ていこう。C# 7よりも先の話でまだ仕様は固まっていないが、現状での仮実装や、検討として挙がっている項目について説明していく。 無効な値の表現 ただし、「具体的にどう取り組んでいくか」の話の前に、「型を使ったnullの許容／拒否の区別」とは別軸で「無効な値を表現するのにnull（0初期化）が適切かどうか」という問題もある。まずはこちらについて話しておこう。 型情報の紛失 nullは、どんな型だろうが一律に0埋めすることで、最
nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編）
Cの系譜を継ぐC#ではnullが長らく使い続けられてきたが、最近ではその存在が大きな問題だと認識されている。前後編でこの問題を取り上げ、今回（前編）はnullを取り巻く事情について考察する。 ← 前回 連載 INDEX 次回 → 近年、nullの存在は、billion dollar mistake（10億ドル規模の損失をもたらす過ち）と呼ばれるくらい忌避されるものになっている。 nullは、低コストでそこそこ安全に参照を扱えるという意味で悪くない妥協ではあるが、技術が進歩した現在ではもう少し賢い参照の扱い方があるはずである。C#のように、これまでnullを認めてしまっているプログラミング言語で、今からそれを完全になくすというのは現実的ではないが、nullに起因する問題を少しでも避ける手段はこれからでも追加していけるだろう。 今回は、nullが生まれるに至った背景から始め、nullが抱える問
バグなどの謎の現象に立ち向かうも闇が濃く、どうしても沼から脱出できない時に見るフローチャート - Thanks Driven Life
ご査収ください (2022年12月8日 追記) フローチャートを書き直しました。内容自体は当時のものと同じです。 補足 パフォーマンスの出し方は人それぞれなので「私はこんな感じです」というものです。 とりあえず「なんかやばいな?」と思ったら休む 体調的にはもちろん、「これ結構やばそうだな?」という勘所は大事 15分以上(長くても30分)悩んだら周りに聞いてみる こういう時はだいたい 視野が狭くなっている(簡単なスペルミスだったり) 暗黙知に触れている(業務だとよくある) とてつもない難問にぶちあたっている といったケースなので、仲間にSOSを出した方がチーム全体の進捗も結果的に良くなる、という経験談です。 ちなみに15分の根拠はなんとなくです。 ちなみに、問題に取り組み始めるその瞬間から「15分やってわからなかったら誰かに聞こう」としている場合は、 フローチャートの「30分動いてなかったら
不寛容社会とエンジニアの「正しさハラスメント」 - エモくありたい
先日、珍しく時間を持て余していたので、テレビを見る機会があった。 バラエティ番組を見るつもりもなく、また、10分ほどだったので、回したのはニュースチャンネル。そのときの題材に「不寛容社会」というものがあった。 何かと繊細な昨今、運動会での組体操でのピラミッド禁止や、除夜の金に苦情がきたために日中におこなうなど、ノイジーマイノリティによる過度な規制や自粛に疑問を示す内容であった。 「不寛容社会」というものは、インターネットにも溢れていると思う。いや、インターネットこそが不寛容社会を助長させていると言っても過言ではない状態だろう。どうあっても必ず誰かが批判をし、それが大きく取り上げられ、最終的には自由が制限される世界はまさに今のインターネットだ。 そうしたインターネットについて述べても良いのだが、今日は少し変わって、「不寛容」という言葉から連想された、エンジニアの「正しさハラスメント」について
技術的負債の返済 – レガシーコードをリファクタリングで救うには | プログラミング | POSTD
レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。
IBM Operations Analytics - Predictive Insights | ハイブリッド・クラウド＆ソフトウェア ソリューションガイド | CloudNavi（クラウドナビ）
IBM Operations Analytics - Predictive Insightsは、システムの動作を学習し普段と異なる異常を検出または予測します。アプリケーションやミドルウェアの問題がサービスに影響を及ぼす前に、それらの問題に対処することで、サービスの可用性とパフォーマンスを強化できます。 ■データの分析と学習：メトリックの変動パターンとメトリック間の相関関係を学習 ■異常挙動の検知：普段と異なるパターンや相関の崩れを異常・予兆として検知 ■障害の回避：異常・予兆を元に事前対処することでサービスの可用性を向上しパフォーマンスを改善 ■根本原因分析の高速化：メトリックの変動パターンや相関関係から障害の根本原因を早期に特定 ■導入と設定の簡素化：複雑なサービス・モデルの定義や特殊なスキルが不要なため運用コストを削減 IBM Operations Analytics - Pr
珍しいSHA1ハッシュを追い求めて - プログラムモグモグ
「SHA1ハッシュってあるだろう？」 放課後、いつものように情報処理室に行くと、高山先輩が嬉しそうな顔でそう言った。 「ええ、SHA1、ありますね」 「SHA1って何桁か覚えているかい？」 「えっと…」 一年下の後輩、岡村が口を開いた。 「50桁くらいはありましたっけ…？」 先輩はパソコンに向かって何かを打ちはじめた。 現在、情報部の部員は三人しかいない。部長の高山先輩と、二年の自分と、後輩の岡村だ。いや、正確に言うと、先輩の学年にはもう少しいたのだが、もうほとんど部室に来ることはなくなってしまった。無理もない、この季節になると先輩たちは受験勉強で忙しくなる。 「例えば、こういうふうに… 適当なSHA1の長さを…」 echo -n | openssl sha1 | awk '{print length}' 部長だけは今も部活に来てこうやって色々なことを教えてくれている。本人曰く、普通に勉強
Atom と PlantUML で快適シーケンス図駆動開発ライフ | DevelopersIO
サーバーサイド開発担当のエンジニアが「設計と実装を進めようとしている」という背景で話を進めます。 PlantUMLは強い 「認識合わせ」という名目でホワイトボードに図を書いて会話することがよくあります。共通言語で会話してあいまいなところを少なくしたら、マネージャーも安心感がありますし、プログラマも自分がやるべきことに集中できますね。 …3日経ちました。あのとき描かれていたホワイトボードの図のとおりに、実装することになりました。認識の齟齬をなくしてくれた貴重な図です。写真に撮りました。どこに保存してたっけ。やっぱり変更したくなったらどうしましょう。またホワイトボードに書き起こす？DRYじゃないですねえ。 そこで、UML図 が登場します。表現したい図を電子データで作成、保存できて、あとで見るときも役に立ちますね。が、しかし、UML図はそれはそれでやや手間がかかるところもあります。作図を助けてく
消えたプログラマの残したものは - megamouthの葬列
システム開発の佳境に、開発メンバーが突然出社しなくなってしまう。 携帯にも連絡がつかず、3日ほど音信不通になったので、さすがに心配になった上司が大家と共に自宅を訪れると、夕日が差し込む部屋の真ん中に、当の本人が何の表情も浮かべずにただ座っていたりする。 そういう事は大して珍しいことではないので、ある程度経験のあるIT業界人なら、同僚が「消えて」しまってもそれほど驚くことはない。 プログラマというのは、とかく「消えて」しまうものなのだ。と彼らは思っている。 「消えた」プログラマは、意識的にしろ無自覚にしろ自分の人生をちょっとばかり台無しにしながら、プロジェクトに虚無の穴を空けるわけだが、そうした「工程の穴」は他のメンバーが残業したり、派遣会社から来た代替の人員が埋めてしまったりする。ビジネス的には人月で数えられた我々の「数字」などというものはちょっとした帳尻あわせでなんとかなってしまうらしい
null安全を誤解している人達へのメッセージ - Qiita
null安全を誤解している人達へのメッセージ 先日koherが投稿した記事が多く読まれたようです。記事の内容は僕とkoherが普段話してきた内容が多く登場しているため、僕が人々に伝えたい内容とも強く合致しています。しかし残念な事にインターネットの反応を見ていると、誤解しているケースが思ったより多くありました。 そこで、ネットで見られた意見に対して返答を書きました。 特定の実在する意見は指さずに、僕が感じ取った文脈を編集したものを対象にします。それによって、「そんな事言われてないじゃないか」と思うものがあれば、僕としてもそのほうが嬉しいのでそれで問題ないです。 「たしかにそうだ」と思ってnull安全に今一度興味をもってもらえれば嬉しいです。 なお、記事中のコードは特に言及が無ければswiftです。 意見: null安全があっても、ちゃんとやるのを忘れているかもしれないのでは 忘れません。ちゃ
DRYと不当な抽象化によるコストについて | POSTD
本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、
ベンチャーにおけるエンジニアマネジメントのキャリアパスは誤解されている | F's Garage
「きっと何者にもなれない自分というエンジニアとしての生存戦略」 という記事が僕の周りでbuzzってた。読んだ限り、そのままでいいんだよ、と、恐縮ながら声をかけてあげたいと思ったわけですが、３点ばかし思うところがあったので雑で恐縮ですが書いてみます。 １．自分は何をしたいのか？願望を持つ重要性 「きっと何者にもなれないエンジニアの生存戦略」として以下の項目を挙げられていた。 1.有名OSSにContributeする。 2.起業する。 3.CxOとしてJoinする。 4.副業として顧問になる。 5.サービスを立ち上げる。 これのいくつか大部分は、「自分がこうしたい」という強い気持ちが必要なので、それがないなら無理に焦らないほうが良い。 OSSでContributeしてる人に話を聞くと、必要に迫られてやったという話をよく聞きます。つまり、issueがあるかないかで変わってくるでしょう。残念ながら
インフラ部門で働くCプログラマの話
12. miruo Pretty-Print TCP session monitor/analizer miruo を⼀⾔で説明するなら「⾒やすい tcpdump」です。当社⽐10倍です、ISUCON 勢に オススメです。TCPセッション毎にパケットをまとめて出⼒するため、パケットの流れが格 段に追いやすくなります。また、問題のなさそうなパケットはあえて省略して表⽰しないの で、興味のありそうなパケットだけが出⼒されます。 $ ./miruo --all -i en0 -m http tcp port 80 listening on en0, link-type EN10MB (Ethernet), capture size 1522 bytes 0001 0.048 | 10.0.0.100:62511 == 125.6.190.6:80 | Total 21 segments, 133
"使える"プロトタイプ主導の開発プロセス - クックパッド開発者ブログ
検索事業部の須藤です。 クックパッドの検索周りのサービス開発を担当しています。 はじめに 最近ではプロトタイピングツールも充実し、コードを書かなくとも動的なモックアップが作れるようになるなど、思いついたアイデアをより早く、より最終的なアウトプットに近い形でメンバーに共有することができるようになったと感じています。 また、実際にコードを書いてユーザーに公開するための効率的な手法や、公開後の検証方法についても様々なツールや知見が共有されており、より精度の高い定量評価ができるようにもなってきたかと思います。 一方、これらの効率化が進んでも、実際に打った施策の数を増やせたか、最終的にサービスインできたプロダクトの数が増えたかというと、そこまで実感がありません。 その理由のひとつは、思いついたアイデアを具体化して作り始めるまでの初期段階と、実際にそのプロダクトを（テスト目的であっても）公開に耐えうる
Scalaの学習コストを下げるための心得 - kmizuの日記
追記：Twitterで、「それって、言語マニアにしかできない技のような気が」という指摘を受けました。自分としては一般的に適用可能な話だと思っていますが、あるいは自分の感性が著しくずれているのかもしれません。その辺承知の上でお読みください。 Scalaは習得が難しい言語だ、とよく言われます。また、実際問題として、Scalaの言語仕様の全体はそれなりに複雑でもあります。しかし、それはたとえばJavaでも言語仕様の全体像を把握するのは難しい話であり、Scalaに限った話ではありません。にも関わらず、Scalaの習得が難しいとよく言われるのはプログラミング言語の学習モデルが誤っているからではないかと最近思うようになりました。そこで、Scala（や他の言語も含めて）のコストを下げるために必要な心得についてちょっと書いてみます。 Scalaはオブジェクト指向言語である これは、Scalaは関数型プログ
「プログラミングは簡単に学べる」という嘘 | UX MILK
プログラミングを学ぶことは簡単なことではありません。それは誰でも知っていることです。 ですが、残念ながら「プログラミングは簡単！」といった文句でビジネスをしようとするマーケターはたくさんいます。彼らのプロダクトを使えば、あるいはそうなるのかもしれませんが。 Hearing the WWDC keynote say coding isn't hard frustrates me. It's extremely hard. You're setting beginners up for huge disappointments. — Tyler McGinnis (@tylermcginnis33) 2016年6月13日 WWDCキーノートで「プログラミングは難しくない」と言っているのは本当に腹が立ちます。ものすごく難しいですから。初心者を騙してがっかりさせるだけです。 誰かがあなたに対してプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webエンジニアが組み込みプログラミングをすることになったときに知っておきたかったC言語の知識 - Qiita
共変戻り値と反変引数 - Qiita
