しょーもない事務作業を快適にするためのツールを作りたいとき 〜セキュア意識の高い会社編〜 - Qiita
Pythonインストールできないんだけど！ なんかいつもこれ同じ作業してるよな、自動化出来ないかな…よしやったる！ ↓ みんなー！こんなツール作ったよー、使ってみてー！ ↓ そして起こる「ちょっと、俺、.pyとかいう拡張子使えないんだけど」の声。 会社のPCって外部のアクセス禁止だったり新規ソフトウェアのインストール制限があったりと、色々制約がありますよね。この制約のせいで、作ったはいいが使えなかった、みたいな理不尽なハマり方したり、一方で試してみたら意外とこれ動いちゃうんだ！？みたいなこともあったりするので、ここではそんなずる賢い業務改善を必死に考える社員のみんなに、どれでやれば利用可能なツールづくりができるのか、その選択肢を載せていくよ。 Python + exe化ツール(Pyinstaller) やっぱ中身含めてファイル操作系でちょこちょこやるならPythonが楽だよね。ただ、Pyt
VSCode上でシーケンス図/クラス図/フローチャートをサクッと書きたい ~Mermaid Graphical Editor~ - Qiita
VSCode上でシーケンス図/クラス図/フローチャートをサクッと書きたい ~Mermaid Graphical Editor~初心者umlVSCode新人プログラマ応援mermaid はじめに Mermaid Graphical EditorというVSCodeの拡張機能にとても感動したので一筆書きました こんな方におすすめ シーケンス図/クラス図/フローチャートをサクッと書きたいけどmermaidとか難しそう 😢 できること VSCode上でポチポチしながらシーケンス図/クラス図/フローチャートを描けるようになる mermaid記法のコードも自動生成されるよ 個人的メリット mermaidの学習コスト0 紙で書くよりも修正しながら書きやすい 導入手順 （簡単7steps） (1) VSCode上で「Mermaid Graphical Editor」という拡張機能をインストールする (2)
ほんとうにあった開発生産性が爆下がりする話 - Qiita
昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。 しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。 この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。 (私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください ) 修正前のコードはコメントアウトで残す 当時、ウォーターフォールで開発していました。 ウォーターフォールでは開発工程とテスト工程が分かれています。 開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。 問題はここからです。 とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
だれかの進捗をうまく把握できないときのフレーズ集 - Qiita
ほとんどの人はだれかと恊働しています。マネージャーやリーダーであるなら、この割合はより大きくなります。 筆者は、仕事の重要な要素のひとつを「進捗を出すこと」と定義しています。そして進捗を出すには、進捗をただしく把握することも重要になってきます。 しかし「進捗を把握する」と言っても、想像以上に難しいと感じる場面が多々ありました。たとえば、 進捗はどうですか？ → 進行中です／〜をやっています なにか問題はありますか？ → とくにないです 〜までに終わりそうですか？ → たぶん大丈夫だと思います というようなやりとりは一般的なコミュニケーションだと思いますが、あまり有用な情報は得られていません。 この記事では、自身の経験則をもとに、進捗にまつわる良い情報をゲットするための具体的な質問を考えてみました。 なぜ進捗を把握すべきなのか 話の前に、なぜ進捗を把握すべきなのでしょうか。 それは良い計画づ
モダンプログラマになれない組込みプログラマの苦悩 - Qiita
はじめに 10年以上組込みエンジニアをしている@yagisawaです。 Qiitaのトップ記事では新しいフレームワークの使い方とかモダン言語の新しい言語仕様の解説とかが流れてきて、いつも羨ましいなーと思いながら読んでいます。 本記事は組込みシステム開発をしていて経験したこと・感じたことを自虐ネタとして書き連ねていこうと思います。他ITエンジニアの人に「うわっ、可愛そう」って思ってもらうのが目標です（ぇ 各業界それぞれに悩みはあると思うので、自分たちが一番不幸とかは思っていません。おそらく隣の芝が青く見えているだけです。それよりあまり組込みの記事は見かけないので、「組込みエンジニアの仕事ってこんな感じ」というのを知ってもらう意図があったりします。 内容によっては「それはあなたの設計が悪いからです」と言われてしまうようなところもあるとは思いますが、建設的なご意見は大歓迎ですが基本は温かい目で見
最近のポケモンはデジモンっぽいのか、ディープラーニングに聞いてみた - Qiita
はじめに ポケモンについて何となく知っている人向けの記事です（デジモンは知らなくてOK） ３月ごろにポケモンたかさおじさんが集計したアンケートの分析をお手伝いしたところ、アンケートの自由記述回答の6353件中、155件もデジモンについて言及するコメントがあった。 「デジモンと区別付かないよね」 「もはやポケモンじゃない…。デジモン…。昔のデザインに戻ってほしいなぁ…。。。」 「主観ですが、伝説のポケモンが角張った印象で、デジモンのような印象を受ける。」 「全体的に毛がなさそうなツルッとしたフォルムの子達が増えた気がします。デジモンっぽい」 「デザインがごちゃごちゃしすぎて子供が描くのが難しい デジモンに近くなってきている」 「ダイパまでのデザインがポケモンっぽいデザイン。それ以降はデジモンみたいな雰囲気。」 私は幼少期からポケモンには触れてきたが、デジモンにはあまり縁がなかったため、 デジ
5歳娘「パパ、変なAPIを作らないで？」 - Qiita
とある休日 娘（5歳）「パパ、一緒に技術ブログを始めない？」 娘「昔から私とパパがローカルに書き溜めてる技術記事が、かなり溜まってきたでしょ？」 娘「それをブログとして公開してみようよ」 ワイ「おお、それは楽しそうやな」 ワイ「どこのブログサービスを使おうかいな」 娘「せっかくなら、ブログシステムから自分たちで作ってみようよ」 娘「私はフロントエンドを担当するから」 娘「パパはRuby on Railsか何かで、APIを作ってよ」 ワイ「おお、Ruby on Railsなら昔やったことあるわ」 ワイ「RailsのAPIモードで、ブログ記事を返すエンドポイントを作ればええんやな」 娘「そうそう」 次の日 ワイ「API、できたで！」 ワイ「/api/articlesっていうエンドポイントにアクセスしてくれたら」 ワイ「ブログ記事が取得できるようにしておいたわ」 娘「さすがパパ」 娘「そういえば
現場で役立つシステム設計の原則メモ - Qiita
This article is a Private article. Only a writer and users who know the URL can access it. Please change open range to public in publish setting if you want to share this article with other users. ※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎ
同じチームにいて最高に心強かったエンジニアの特徴をまとめてみた - Qiita
これまで私はプロダクトマネジメントやデザインディレクションを行う立場として、BtoBにBtoC、iOSにAndroidにWebにWatchOSにIoT、ゼロイチにグロース。様々な分野、プラットフォーム、フェーズでサービスを開発する機会に恵まれてきました。 その中で一緒にチームを組んだフロントエンド、サーバーサイド、iOS、Android、インフラ、データ、様々なエンジニアの方を思い出しながら「ああ、心強いな」と感じた色々なタイプの特徴を、リスペクトの想いを持って、プロダクトマネージャーやデザイナーの視点でまとめてみました。 それではいってみましょう。 目的にフォーカスしている 要件をただ実装するのではなく、ビジネスの目的はなにか、ユーザーが真に求めているものはなにか、なにがサービスの生死を分けるのか、技術は目的を達成するための手段だと客観的に捉え、真の目的に対して解決策を提案し続けてくれる
日立社員「社内からQiitaに投稿？できるのそれ」 - Qiita
(2019-12-18 表現を一部訂正しました。) メタ記事。投稿するのにかかる手間に関する投稿です。 1 どうしてこんな記事を書こうと思ったか 日立製作所もガンガンOSS活動をしていることを知ってほしい。日立に興味があるが、OSSコントリビューションは社外発信にどれくらい熱心なのか気になる人向けに、とある一部署の情報をシェアしたい。 タイトルのような感想を持つ弊社内の人に情報発信してもらいたい。 (残念なことに、) 社内の情報共有サイトに書くよりQiitaに書いたほうが読まれそう。 後輩がAdvent Calendarの記事集めに苦労していたので気の毒になったため 注: 全社的な審査プロセスではなく、(株)日立製作所 ITプロダクツ統括本部のやりかたです。 では全社的なプロセスは？他の部署は？ → 詳しい方、（申請の上）コメントください。 ITプロダクツ統括本部って何？ Google i
いつものように本番作業してたはずなのに - Qiita
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019」の1日目です。 https://qiita.com/advent-calendar/2019/yarakashi-production なかなか濃いラインナップが期待されますが、まずはさらっといきたいと思います。 具体性が乏しい部分もあると思いますが、そこはお察しください。。。 やらかし 背景（前提条件） いっていに昔の話です ETL（データ加工）サーバ 数十を超えるシステムからデータを集める BIツールなどで活用できるように各種加工処理を行い、DBなどにロードする 繁忙の違いはあれど、24/365で常時一定量の処理は稼働している 複数のチームが共存しているサーバ アプリ面では比較的疎 ETL処理のリリース前に本番サーバ上で試験をする取り決めになっていた 性能や本番相当データのテストが安全に行えるような環境
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
slackで「投稿ルールが守られない問題」を自作のスラッシュコマンドで解決する(設定編) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? slackあるある ※※お知らせ※※ 今後、備品購入を希望される方は当チャンネルで ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 【購入品名】 ： 【購入URL】 ： 【購入承諾者】： 【納品希望日】：2019/mm/dd 【備考】 ： ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ というフォーマットを使って下さい。 (ピンどめしておきます) 現実は・・・ フォーマットを自己流に改変する人 そもそもフォーマットを使ってくれない人 別のチャンネルで依頼する人 etc..... 解決策 今後、備品購入依頼は 当チャンネルで /bihin と投稿し、 表示される
早すぎる抽象化の危険性(その抽象化、今のタイミングで大丈夫ですか？) - Qiita
※ 色々と誤解を招くというご指摘を受けたためタイトルを変更しました 早すぎる抽象化の危険性 ↓ 早すぎる抽象化の危険性(その抽象化、今のタイミングで大丈夫ですか？) 元の記事の趣旨としては、 抽象化をするな という訳ではなく、 その抽象化は本当に今すべきなのか一歩立ち止まって考えろ ということだと思っております。 何か不適切な点などございましたらご指摘頂けますと幸いですm(_ _)m ~~ 以下本文 ~~ ちょっと前の記事なのですが とても印象深く 今後も気をつけていきたいと思い 自分なりにまとめてみました。 早すぎる抽象化とは？ 問題になっていることを十分に理解する前に 可能性のあるすべてのパターンを把握しきる前に 抽象化をしてしまうこと ※コメントでのご指摘がありましたように 「早すぎる抽象化」はの結果として 「誤った抽象化」に陥ってしまうことが問題であり、 定義を下記のように修正しま
侍エンジニア塾の解約・返金に成功したので公開するby弁護士プログラマ - Qiita
という破格！！ これだけでもパンチが効いていますが、さらに凄いのが、そのSEO対策の能力で、技術系の検索をすると検索上位に関連サイトが次々表示されます。 また、Javascriptを駆使した景表法違反事件でも炎上しましたね。 炎上を取り上げた株式会社アクシア様のブログ さてさて、前置きはこれくらいにして、解約までのストーリーを公開します！ 侍エンジニア塾に入塾 ２０１８年冬のことでした。 2年以上、Pythonで機械学習やったり、LineBot作ったりしながら遊んできた私、とうとう肩書にプログラマを加えたいと思うようになりました。 そのためにはプログラミングでカネを稼がなければいけません。 そこで、コードを書いてとりあえずデプロイして少人数で遊ぶレベルから、プロダクト制作できるレベルにアップしようと決めました。 保守・運用・コスト管理などの総合的スキルを身に着けたい＋ハクをつけたいと思い、
iPadでプログラミングしてる人、今まで馬鹿にしててすみませんでしたァァァァ!!!! - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こちらの記事内容は3年以上前のものなので、記事内にあるアプリケーションなどの動作やUIは実際と異なる可能性があるのでご注意ください。 (2023/01/04追記) iPadでプログラミングwwwアホちゃうかwww ワイ「え？お前全部iPadでプログラミングしてんの？そんなん効率悪いに決まっとるやんw」 ワイ「せいぜいでっかい画面でGithubのコード眺めるくらいしかできないやろwてかハイライトすらないんじゃn」 ?!(Monokaiで表示されとるやんけ...) ワイ「おっ、おう。シンタックスハイライトくらいはできるんやな。」 ワイ「まあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【魚拓】ほんとうに怖い。さくらのレンタルサーバー - Qiita
【魚拓】Webエンジニア業界に感じた違和感 - Qiita
アセンブリに触れてみよう - Qiita
