エンジニアが画面設計（Figma）を担当してみた振り返り
Thinkings株式会社 では sonarATS の開発にあたり、基本的にはデザイナーがFigmaを作成し、それに基づいてエンジニアが開発するというフローを取っています。 そんな中、先日エンジニアサイドで画面設計を行ってみるという実験的な取り組みをしました。 本記事では画面設計を行うことになった経緯と具体的な取り組み内容を振り返り、エンジニアが画面設計をすることのメリットと課題感について考えたことをまとめたいと思います。 エンジニアサイドで画面設計をするきっかけとなった要因 エンジニアサイドで画面設計をすることとなった理由として、大きく分けて以下３つの要因がありました。 デザイナータスク削減の目標 あるマスタ画面を開発したときの課題感 上述の通り、『簡単なマスタ画面の開発』のような共通的な画面設計になる機能については、できるだけデザイナーが介入せずエンジニア主導で開発している → 実際に
技術文書の書き方
howto-tech-docs.md 技術文書の書き方 このメモは、私（@ymmt2005）が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
「技術同人誌をMarkdownで書く」とは、実際どういうことか？｜藤原 惟
※ この記事はすべて無料でお読みいただけます。投げ銭歓迎。 ※ またこの記事は「技術同人誌 Advent Calendar 2018」の4日目です。 ※ 12/4 22:34 追記・微修正 以下、技術同人誌を書きたい方・既に書いている方に向けて書いていきます。（Markdown一般の話に比べると、やや高度なことを説明しようとしています。あらかじめご了承ください） ---------------- 技術同人誌という存在を知り、自分でも書きたくなったITエンジニア（特にWeb系）にとって、 「技術同人誌を書くなら、Markdownで書きたい！」 という魂の叫びは当然のことでしょう。 Markdownを使ってブログを書き、簡単な図ならmermeidやPlantUMLで直書きし、プレゼン資料まで作ってしまうMarkdownフリークであれば、「技術同人誌ぐらい、Markdownで書けるはずだ！」とい
Read the Docs(Sphinx)でオープンソースのドキュメントをいい感じに書いてみる
B! 139 0 0 0 最近良くGitHubなんかで公開されてるオープンソースのドキュメントを見ようとすると こんな感じの似たようなフォーマットで書かれているものが多くなっています。 余りに多いので最初GitHubのサービスかな、とか思ったんですが、 これはまた別のRead the Docsという ドキュメント用ホスティングサービスによるものでした。 Read the Docs Read the Docsでドキュメントを公開してみる Sphinxのインストール レポジトリ側の準備 Read the Docsへの登録 ページを作成 Indexページ ページ内容の編集(Markdown to reStructuredText) タイトル ハイパーリンク 画像 リンク付き画像 インラインマークアップ コードブロック リスト テーブル Pythonのモジュール説明 その他reStructured
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
