ストックマークの社内研修の公開版※資料です。 (※実際に研修で利用したものとは異なります)
![マネージャー&リーダー向け 社内トレーニング / Training of management and leadership for Stockmark](https://cdn-ak-scissors.b.st-hatena.com/image/square/cc250640a3d907c2203bdc917194c34308e3f49d/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F0fb86a4431174a9e85588c3c010831a4%2Fslide_0.jpg%3F26575144)
管理画面であれば社内の人くらいしか使いませんので、あまりデザインにこだわる必要がないのでベタなBootstrapを使ってもそんなに嫌がられることはないでしょう。とは言えちょっとは格好よく見せたい場合もありますよね。 そんな時に使ってみたいBootstrapテーマがHierapolisです。フラットなデザインで格好いい管理画面用テーマとなっています。 Hierapolisの使い方 Hierapolisはサイドバーがついていて、一覧性がある管理画面が作れます。デザインはフラットだけにシンプルで、各機能に素早くアクセスできるのが特徴です。使い勝手が良いのではないでしょうか。 HierapolisはHTML5/JavaScript製のオープンソース・ソフトウェア(MIT License)です。 Sign in lab2023/hierapolis
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
Azure を探索 Azure について 安全かつ将来を見据えた、オンプレミス、ハイブリッド、マルチクラウド、エッジのクラウド ソリューションについて調べる グローバル インフラストラクチャ 他のどのプロバイダーよりも多くのリージョンを備える持続可能で信頼できるクラウド インフラストラクチャについての詳細情報 クラウドの経済性 Azure の財務上および技術的に重要なガイダンスを利用して、クラウドのビジネス ケースを作成する 顧客イネーブルメント 実績のあるツール、ガイダンス、リソースを使用して、クラウド移行の明確なパスを計画する お客様事例 成功を収めたあらゆる規模と業界の企業によるイノベーションの例を参照する
2013年11月18日 追記 この記事を書いた後、何人かのかたから「うちでは同じApple IDで両方とも使えているよ」というご指摘をいただき、 Member Centerのほうにアカウント追加 -> iTunes Connectに同じアカウント追加という順番だと「警告は出るもののかまわずContinueすれば」同じApple IDでアカウント作成可能 iTunes Connectにアカウント追加 -> Member Centerに同じ追加という順番だと「複雑な手順にはなるものの適切な手順を通せば」同じApple IDでアカウント作成可能 失礼しました。 追加情報などあれば是非おねがいします! 概要 私はiOSアプリの開発を3年以上やっていますが、恥ずかしながら会社でこのためのアカウントを管理/運用する方法をきちんと把握できていませんでした。 というのも個人で開発するぶんにはそんな管理は必
部下がいるにもかかわらず、自分で全てやってしまった方が早く終わるし、煩雑さがなくなる……そんなことをしてはいませんか? 仕事ができる30代の新人リーダーに多いこの状態。もはや「自分でやった方が早い病」です。そこで今回は「自分でやった方が早い病」の治し方をご紹介します。 ■「自分でやった方が早い病」はなぜ病なのか?仕事をする上で、「自分でやった方が早い」という考えに陥ってしまう、この病は結局、他人に仕事を押し付けないためと言っておきながら、自分の利益しか考えていません。仕事を部下に回すことは部下の成長にもつながるにもかかわらず、全て自分一人でやってしまうのは、周囲の人間とともに成長する姿勢を持っていないということなのです。 病状が悪化してしまうと、「孤独な成功者」になってしまいます。仕事を私生活に抱え込むことも多く、いつまでたっても優秀な部下を育てることが出来ず、誰も信頼できなくなります。す
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに1個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
capability maturity model integration / SEI CMMI / 能力成熟度モデル統合 / CMM統合 専門分野・改善作業内容別に複数存在していたCMM(注1)を整理・統合し、分野横断的な改善活動で利用可能な手引きとして定義・策定されたプロセス改善モデル。世界中の組織・企業でCMMを利用した結果をフィードバックして、より効果的なモデルとして作られた。 1980年代半ばにカーネギーメロン大学 ソフトウェアエンジニアリング研究所(CMU/SEI)で開発が始まったCMM(SW-CMM)は、ソフトウェア開発のプロセス改善において大きな成果を示した。この成功は、さまざまな分野で類似の改善モデルを多数生み出すことになった。 これらのモデルは各分野の特定プロセスに適用するには有用だったが、大規模な組織が複数の異なるプロセス同士を横断的に連携して改善活動を行おうとする場
Pythonで書かれたレビューツールです。VMware社内で利用されていることで有名なツールです。 プレコミットレビューという概念のレビューツールです。つまり、コミット前にレビューをするという事が前提になっているツールです。よって、結果的に差分を重点的に確認していくツールのつくりになっています。 rietveld rietveld – Code Review, hosted on Google App Engine – Google Project Hosting Google社内で使われているコードレビューツールである「Mondrian」のオープンソース版です。基本的にGoogle App Engineで動くことが前提になっています。 GAEの上のコードのデータを置くということがオトナの事情的に難しいかもしれませんが、検討してみてください。 Phabricator Phabricator
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model(上記は翻訳記事)を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
サービス提供終了いたしました。ご愛顧ありがとうございました。 2023年2月7日 株式会社グルーヴィーメディア
ベテランを悩ます“いまどきエンジニア” ~ 立ちはだかるコミュニケーションの壁:いまどきエンジニアの育て方(1)(1/3 ページ) 「若手とコミュニケーションが取れない」――。このような悩みを抱えるベテランエンジニアは少なくありません。育った時代背景も価値観も大きく異なる世代同士で、スムーズに仕事を進めるにはどうすればよいのか。製造業の開発現場に詳しい著者が、ベテランエンジニアや管理職の皆さんに向けて、若手と向き合い、育てていくヒントを提示します。 →「いまどきエンジニアの育て方」連載一覧 育たない若手エンジニア 「若手がなかなか育たない」、「現場のOJT(On the Job Training)が機能しない」――。ここ2年ほど、メーカーの開発現場の部課長クラスや、人事部門から、こうした声が急に目立つようになりました。 若手のエンジニアを一人前に育てていく。エンジニアに限らず、いつの時代も
やっと暖かくなってきて桜もチラホラと咲き始めましたね。こんにちわ、シックス・アパートの高山です。 さて、今回はMovable Type に限らずですが、開発の根幹と言えるコード管理についてお話をしたいと思います。 ご存じの方も多いかと思いますが、Movable Type は現在 github 上で開発が行われています。(セキュリティ・フィックスの際には、社内のgitサーバでひっそりと開発が行われます。)gitに移った事を期にブランチ管理のやり方も変えています。 ちなみに、現時点でのブランチはこうなってます。 % git branch -a remotes/origin/HEAD -> origin/master remotes/origin/develop remotes/origin/develop-backuprestore remotes/origin/feature-assetdr
Mac App Store is the simplest way to find and download apps for your Mac.To download Apple Configurator from the Mac App Store, you need a Mac with Mac OS X 10.6.6 or later. Learn More. Description Apple Configurator makes it easy for anyone to mass configure and deploy iPhone, iPad, and iPod touch in a school, business, or institution. Three simple workflows let you prepare new iOS devices for im
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く