デザインシステムは最優先にはならないです
どちらかというと優先順位は低めですデザインシステムの必要性を説く時代は終わりましたが、その利用促進や運用継続は容易ではありません。デザインシステムの構築者とプロダクト設計者が同じ人物であるような小規模組織では、ガバナンスの課題は些細なものばかりです。また、コミュニケーションが活発な小さな開発チームなら、メンバーのモチベーションが続く限り、維持・管理は比較的容易です。 組織が大きくなり、様々な体制やプロセスを持つ複数のプロダクトが存在する場合、全員一丸となってデザインシステムを取り組むのは難しくなります。その結果、「作る側」と「使う側」に分かれがちです。この問題を解決するため、各プロダクトから代表者を集めて議論する連邦制のような体制が考えられます。しかし、デザインシステムへのコミットメントを本業と両立させるのは容易ではありません。 プロダクトの開発と改善に集中しているチームにとって、デザイン
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
JavaScript Primer 2.0 - ECMAScript 2020に対応した入門書を公開しました
ECMAScript 2020の変更に対応したJavaScriptの入門書としてJavaScript Primer 2.0.0を公開しました。 JavaScript Primerのウェブサイトから閲覧できます。 ウェブサイト: https://jsprimer.net/ サマリIssue: ECMAScript 2020の対応 · Issue #1145 · asciidwango/js-primer 変更内容の詳細はリリースノートを参照してください。 Release 2.0.0: ECMAScript 2020対応 · asciidwango/js-primer 2.0.0の目的 JavaScript Primerは、継続的にメンテナンスするためにOSSとして開発しています。 ECMAScriptの仕様は年に一度アップデートされていて、現実でのJavaScriptの使われ方も変化していく
真面目な人を本気にさせる方法
先日、他社の開発の方々が、アジャイルに関する相談ということで、弊社にいるアジャイルに詳しい髪の長いおじさんに訪ねてきた。その中で、実感駆動開発の話になって、久しぶりに「本気（マジ）と真面目（マジメ）」の話を聞いた。 この話を聞いてから、人がプロダクトの価値について考えられるようになるにはどうしたらいいのか考えてみた。 TL;TRありきたりな回答だけれど、さっさとリリースして、さっさと使ってもらう。それをできるためのことを、もちろんリスクを下げつつ、できるようにするためのことを頑張ろう。 本気と真面目 人はドキュメントを前にして真面目な態度を取るが、動くソフトウェアを前にして本気になる。端的に言うと、人は仕様書などドキュメントを前にするとそれを徹底的に重箱の隅を突くようなレビュー（真面目）をしてしまうが、本当に欲しかったことに対して考え始める（本気）は実際のプロダクトを前にしてからという話だ
「一つのことをうまくやる」に忠実たれ。Serverspec開発者mizzyが語る成功するOSSの設計｜ハイクラス転職・求人情報サイト AMBI（アンビ）
「一つのことをうまくやる」に忠実たれ。Serverspec開発者mizzyが語る成功するOSSの設計 過去、手動と目視による作業が常だったサーバーのテストを圧倒的に簡易化するServerspec。国内外で高い評価を得るこのOSSの開発舞台裏を、作者の宮下剛輔（mizzy）さんが語ります。 2014年1月、世界中の優れたオープンソースプロジェクトを表彰するアワード「Open Source Rookies of the Year 2013」で、日本発のあるツールが選定されました。Dockerなど名だたるソフトウェアと並んで入賞したそのツールの名は「Serverspec」。 Serverspecとは、一言で表現すれば、サーバーのテストを自動化してくれるオープンソースソフトウェア（以下、OSS）のツールです。過去、手動と目視による作業が常だったサーバーのテストを圧倒的に簡易化するServerspe
Swift API Design Guidelinesの紹介(Swift 3版) - Qiita
Swift.org - API Design Guidelinesを読みながら日本語で書き起こしてみました。 (全訳では無く、また一部意訳など混ざっています。) API Design Gudelinesということで、例えばアプリ実装の特に画面側のコード書く際にはあまり気にしなくても良い気がするものも少し混ざっている気がしました。 原文に豊富にあるコード例はほとんど省いたので、適宜原文見た方が分かりやすいかと思います。 基本 用途が明確なこと 用途が明確なことは、最も重要なゴール。コードは書かれるより読まれることの方がずっと多い。 明確さは簡潔さより重要 短いコードを追い求め過ぎて、可読性など損なうのは良くない。 ドキュメンテーションコメントを書きましょう すべての定義にはドキュメンテーションコメントを書きましょう。 (訳注: 処理に添えるコメントではなくクラス・メソッド・フィールド定義など
Document Revision History: This table describes the changes to The Swift Programming Language.
This content has moved; redirecting to the new location.
翻訳: WebAPI 設計のベストプラクティス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
APIデザインにおける七つの大厄介 | POSTD
(編注：2016/7/29、頂いたフィードバックを元に記事を修正いたしました。) APIをデザインするということは、科学であり技術でもあります。多くの頭の良い人たちが失敗を重ねてきました。成功している人たちは、APIの主な目的を念頭においてデザインしているのです。その目的とは、「開発者たちをウンザリさせる」ということです。 親愛なる仲間たち、その崇高っぽい追求を称えるべく、「APIデザインにおける七つの大厄介」を共に数え上げようではありませんか（私がしたことを見てください）。 リスティクル（箇条書き形式の記事） を書くつもりはないのですが、少なくともタイトルは 教養ある宗教的文献が参照元 です。 まず、ルールを決めましょう。ここでは、成功し、きちんと機能しているAPIを取り上げます。ですから、「動かない」とか、「大量のセキュリティホールがある」といったことは厄介ごとに数えません。「致命的」
Python と型ヒント (Type Hints) - forest book
先日、Python の静的型チェッカーとして mypy を紹介しました。 mypy で静的型付け Python プログラミング - forest book 私には難しくてまとめきれないため、Guido が参照している漸進的型付け (Gradual Typing) も含め、また別の機会に、、、。 とか言っているうちに1ヶ月ほど経ってしまいました。 そうこうしているうちに PEP のドラフトも出てきたので区切りとしてまとめておきます。一通り調べたことを基にして書いていますが、私の誤解や勘違いもあるでしょうから怪しいところがあったら調べ直してみてください。もちろんツッコミも大歓迎です。 型ヒント (Type Hints) を導入するという提案 PEP 483 - The Theory of Type Hints | Python.org PEP 484 - Type Hints | Python
Javadoc ドキュメンテーションコメントの書き方 - Qiita
そもそも、そのメソッドの作成者が近くにいない場合、こういった確認すら行えません。結局、あるメソッドを使うために、そのメソッドの実装を時間をかけて分析することになるため、複数人で開発していることが、逆に開発効率を悪化させてしまいます。つまり、簡単に言うと、 「仕様の明確でないメソッドを作るのは迷惑行為です！」 ドキュメンテーションコメントによって API 仕様が明確にされていれば、こういった無駄なやりとりがなくなるため、開発効率もコード品質も上がります。下記のグラフは、開発メンバの人数と、生産性の関係を表しています。 仕様の不明確な API が溢れているプロジェクトに新しい実装メンバを投入しても、開発効率はうまく上がっていきません。すべての API の仕様が明確になっていれば、不具合が見つかった場合でも、各メソッドが何を実現すべきかが分かるので、別の人が実装を引き継いで修正していくことが可能
vim-jp » Vim の作者 Bram Moolenaar への 10 の質問
10 Questions with Vim’s creator, Bram Moolenaar - Binpress の翻訳です。 Vim の作者 Bram Moolenaar への 10 の質問 by Alexis Santos, November 19, 2014 Vim の登場から 23 年、何百万行ものコードが Vim で書かれました。私たちはこの偉大なテキストエディタの作者である Bram Moolenaar にお話を伺い、20 年間の開発で彼が学んだことや、NeoVim についての彼の考えなどを聞きました。また、Reddit の Vim ユーザーからの質問も投げかけてみました。Bram の回答をご覧下さい。 1: このような大きくて広く使われるソフトウェアを長期間メンテナンスすることから学んだことは？ 人が間違う可能性のあるあらゆることを学びました。自分自身の失敗や他人のコード
コマンドラインツールについて語るときに僕の語ること #yapcasia
http://yapcasia.org/2014/talk/show/b49cc53a-027b-11e4-9357-07b16aeab6a4
小飼弾、Swift愛を語る「2014年前半のインパクトは間違いなくSwift」 - エンジニアtype | 転職type
2014.08.18 スキル 業界で名の知れたプログラマーは、今年の上半期に何を学んでいたのか？ 「同業者が役に立ったものは、自分にも役に立つはず」という仮説を基に、彼らの学びlogから、2014年上半期の流れを振り返り、今後の動向を予想してみよう！ アルファブロガー 小飼 弾氏（@dankogai） 1969年生まれ。カリフォルニア大学バークレー校を経てオン・ザ・エッヂ（のちのライブドア）へ入社し、その後、取締役就任。96年にディーエイエヌを設立し、現職に。読書家としても知られ、ブログ「404 Blog Not Found」での書評は毎回、大きな話題を集めることでも有名。ニコニコ生放送にて、「プログラマー脳で今時のニュースを一刀両断する」放送を行っている。共著書、著書、多数 日本時間の2014年6月3日、WWDCの席上でAppleが新言語『Swift』を発表した。そしてその翌日の6月4日
Readme Driven Development
Readme Driven Development 23 August 2010 - San Francisco I hear a lot of talk these days about TDD and BDD and Extreme Programming and SCRUM and stand up meetings and all kinds of methodologies and techniques for developing better software, but it’s all irrelevant unless the software we’re building meets the needs of those that are using it. Let me put that another way. A perfect implementation of
OpenGLでムカつくこと
Rich Geldreich's Blog: Things that drive me nuts about OpenGL Valve社員のRich Geldreichが、OpenGLの設計が古臭すぎることについて不満を爆発させている。 OpenGLについてムカつくことを脳内ダンプしてみる（これは個人的な件秋であって、Valveや同僚の見解ではない。あと、ここ数年、OpenGLと格闘してきたので、今日は機嫌が悪い）。これを投稿する理由はこうだ。GL APIには再設計が必要だ。というのも、思うに、MantleやD3D12がどうせ昼飯前にOpenGL APIを駆逐してしまうだろうから、この問題については、今考える必要があるのだ。 ここに見れば些細な問題もある。単にAPIのトレースの問題というのもある。しかし、それらの問題が積み重なって、他の開発者にGL APIという環境に飛び込むよう誘うのを躊
overlasting.net
overlasting.net 2020 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
