非エンジニアメンバーを巻き込んで少しずつ自動化を進めた話 - Qiita
こんにちは！横断本部わり算グループのしげるです。 9日目は @kentaro_suzuki さんで 最近読んだGo言語の本の紹介：100 Go Mistakes and How to Avoid Them でした。明日で、アドベントカレンダーも最後ですね。 趣味で、社内の自動化をいくつかお手伝いしています。 4日目に、 Google Apps Script(GAS)を使い倒して、アンケート作成を自動化した話 もあげているので、興味があれば、読んでください。 今回は自動化の案件を元に、普段意識していること、自動化案件が成功するための秘訣について共有できればと思います。 先に端的に 3行で、伝えたいことをまとめると次の3行になります。 自動化した後に、運用するメンバー(カスタマーサポートのTさん)を巻き込む 定期的に時間を確保する やりたいことの本質を考える 案件 今回紹介するのは、lucca
企業主催の技術カンファレンスをハイブリッド開催して思ったこと - Qiita
こちらは 技術広報 Advent Calendar 2022 の8日目の記事になります。 はじめに こんにちは。 @yutaka_sashima です。普段はグリーで技術広報を担当しています（と思われています）。 いきなり歯切れの悪い自己紹介になっちゃってますが、実際問題グリーには技術広報という職種はありません。 でもなんとなく外の人からそれって技術広報じゃんと言われることが多いので、きっとそういうことなんだろうと思いこちらのアドベントカレンダーに参戦させていただきました！ 技術広報が取り扱うトピックはかなり振れ幅が大きいので、ここでは企業主催の技術カンファレンスにフォーカスしてみたいと思います。 （、、、とは言えここにフォーカスして読者のみなさまの役に立つのかどうか不安だったので、ChatGPTに聞いてみました。） 微妙。。でもこのトピックでいきます！ 企業が技術カンファレンスをやる意義
配信のプロではない技術広報が率先して行う生配信で失敗しないためのTips - Qiita
こんにちは。@techfavoです。普段はクックパッドのCTO室で技術広報やその他諸々の業務を行っています。 この記事は『技術広報 Advent Calendar 2022』の二日目の記事として、皆さまへ配信オペレーションに関するいくつかの教訓をシェアできればと思います。 はじめに この記事をお読みになっているということは、何かしら技術広報の活動に関心がある方だと思われます。技術広報の役割として、社内の技術領域を広めるために技術ブログ、カンファレンス、勉強会の運営などを行なっている方も多いのではないでしょうか？ しかし現在において忘れてはいけないのが動画。そう配信です。 ググってみたら、Youtubeの利用率は87.9％もあり、ほぼ全ての日本人がYoutubeで動画や配信を視聴していることになります（ https://grove.tokyo/media/g0181/ ）。 この巨大なプラッ
スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、その効果と苦労点 - Qiita
スタートアップである弊社が全員ほぼ未経験でRuby on RailsをScalaに移行した理由、その効果と苦労点RubyRailsScalaポエムスタートアップ この記事を書くに至った経緯 僕が代表をしている株式会社KOSKAでは製造業の原価管理をIoTで自動化するGenkanというサービスを提供しております。 そんな弊社では半年前、バックエンドをRuby on RailsからScalaに移行したのですが、その効果が思ったよりだいぶ大きく、いずれこの効果を共有したいなーと思っていました。 弊社ではスタートアップで全員ほぼ未経験状態のScalaを採用するという挑戦をした結果、「Scalaを書きたい」というレベルの高い人材をかなりの確率で捕まえられるようになり、開発がものすごい加速した上に堅牢になったのでそのうちスタートアップでScalaを採用するメリットを記事にする予定。 https://t
ActiveSupport::Callbackを使うのをやめろ - Qiita
追記: 個人的な最終結論が出たのでそちらをまとめました。 続・ActiveSupport::Callbackを使うのをやめろ 概要 タイトルは1年ちょっと前の自分に向けた自戒なので絶対に使うのが悪というわけではない(と思う)。 だがぼくにはうまい付き合い方が見つけられそうになかったのでやめろという強い口調を意図して使っている。 ActiveSupport::Callback is 何? これ→activesupport/lib/active_support/callbacks.rb Railsガイドにも記載されているのでRailsチュートリアル完走するかそれ相当のことをしていたら使う使わないは別にして知っているだろうと思う。 Active Record コールバック # サンプルでよくみるやつ class User < ApplicationRecord after_create :sen
ruby製Webフレームワーク hanami紹介 - Qiita
はじめに この記事は，SLP KBIT Advent Calendar 2017 の5日目の記事です． hanami という ruby製Webアプリケーションフレームワークの紹介を微力ながら，Railsユーザー向きに書きたいと思います． hanami とは Hanami is a modern web framework for Ruby. トップページに４つの特徴があったので紹介します． 1: Fast response times hanamiはスピードに合わせて最適化されています。ミリ秒単位で応答を返します。CDNを最大限に活用することで、より迅速なアプリを作成できます。 2: Full-featured, but lightweight メモリを犠牲にすることなく強力な製品を構築するために提供している100以上のAPIを使用することができます。 hanamiは他のフル機能のRuby
見たいエンジニアの職務経歴書の書き方 - Qiita
前置き 某上場Web系の企業で中途社員のサーバーサイドエンジニアの書類選考や採用面接官などをしています。途中に転職もしましたが面接などの採用に関わり始めてから５年経ちました。 以前に面接についてはこちらの記事を書きました。 エンジニアを面接するときに面接官が本当に知りたいこと 書類選考もしていて、欲しい情報が足りない。本当の実力はもっとあるのでは？と思うこともあり、今回は採用側の立場から、もっと見たい職務経歴書の書き方について書こうと思います。 全てのパターンに当てはまることはなく、主にWeb系の中でもそれなりに大きな会社の中で見てきた観点での話になります。 今回もWeb系の大手企業に入る観点での職務経歴書という前提が付くかもしれません。 しばしば見る、情報が足りない職務経歴書 採用を決めるマネージャがエンジニアでない場合や技術の深さに疎い場合、技術に関してそれなりの評価しか出来ません。
自宅サーバーでTwitter連携サービスを運営してたら家宅捜索された件 - Qiita
概要 ある朝自宅に神奈川県警が乗り込んできた。 (なお自宅は神奈川県ではない) どうやら俺はTwitterにモロ画像を投稿していたらしい。 「間違いなくこの家から投稿されていた。プロバイダにも確認済みだ。」 「(ハンドルネーム)というアカウント使ってるでしょ」 「心当たりあるでしょ？」 「(ブランド名)のTシャツ持ってるでしょ？」 おやっ、何かがおかしいです。 想定される経緯 自宅サーバーではTwiGaTen( https://twigaten.204504byse.info/ )というWebサイトが稼動している。 そしてこいつはTwitterアカウントでログインしたアカウントのタイムラインを24時間365日収集し続けている。Twitterの仕様上、これは時々ログイン履歴として記録される。 そして警察はモロ画像をうｐしたアカウントのログイン履歴を見て… 「固定回線からうｐか。バカめ。」 「
そろそろポリモーフィック関連について一言いっとくか - Qiita
class Notification < ActiveRecord::Base belongs_to :notifiable, polymorphic: true end class Message < ActiveRecord::Base has_one :notification, as: :notifiable end class Like < ActiveRecord::Base has_one :notification, as: :notifiable end 一行で色んなクラスに対する関連が指定できて便利感がある。 だからって、これを安易に使う前にちゃんと考えよう。 ポリモーフィック関連は単に関連の定義を省力化するためのものじゃない。 ポリモーフィックという名前が示す様に、これは多態性を持ったものに対する関連を定義する事であって、インターフェースに対する関連の定義だということ
Rubyのインクリメント速度のバージョンごとの比較 - Qiita
TL;DR Rubyでは i++ ができない。 たまたま i++ しようとしたらエラーになったのでそういえばインクリメント演算子がRubyだと出来なかった気がするなと思い、念のために調べてみた。 公式ドキュメントじゃないけど、割と自明な話しだと思うので公式ではなく個人のテックブログを参照した。詳細に調べられていたので問題ないかなと思う。 そして恐らくだが以前も同じブログを参照した気がする。 Ruby にインクリメント演算子のようなものが無い理由 選択肢としてはi += 1とi.succ、i.nextの3パターンあるがなにが違うのか気になったので調べたところ先人がすでに調べていた。 RubyのIntegerにおけるsuccとnext ただこの記事も前述の記事も2014年〜2015年なので現在のRubyバージョンでは状況が変わっている可能性があるし、なんなら自分が問題を起こしたバージョン(ru
ブラウザでVS codeが使えるクラウド IDEの大本命「Coder」 - Qiita
TL;DR ブラウザ上でほぼVS codeが使えるクラウドIDEサービス「Coder」 他のVS codeライクのクラウドIDEと異なるのは「拡張機能がそのまま使える」。大半の拡張機能を利用可能 現在はアルファ版 ChromebookやiPadでの利用も想定している Dockerコンテナにプロジェクトを作成するので自由度が高い 無料プランでも十分に使える。他のクラウドIDEと比べて月額費用が安い Fast Time機能を使うと時間制で96CPUコア、メモリ16GBが利用可能(課金で殴る開発駆動) コラボ機能で1つのプロジェクトで複数ユーザでペアプログラミングができる(未確認) きっかけ 2019年2月28日の夜、「あれ、VS codeライクなクラウドIDEってなんて名前だっけ？」という疑問から 「Cloud IDE vs code」 でググったところ以下の検索結果が表示。 ここで目的である
iPadでプログラミングしてる人、今まで馬鹿にしててすみませんでしたァァァァ!!!! - Qiita
こちらの記事内容は3年以上前のものなので、記事内にあるアプリケーションなどの動作やUIは実際と異なる可能性があるのでご注意ください。 (2023/01/04追記) iPadでプログラミングwwwアホちゃうかwww ワイ「え？お前全部iPadでプログラミングしてんの？そんなん効率悪いに決まっとるやんw」 ワイ「せいぜいでっかい画面でGithubのコード眺めるくらいしかできないやろwてかハイライトすらないんじゃn」 ?!(Monokaiで表示されとるやんけ...) ワイ「おっ、おう。シンタックスハイライトくらいはできるんやな。」 ワイ「まあ、考えてみればそのくらいは余裕だわなwでもな〜wコードだけ書けてもプレビューは？流石にそれが出来ないことには使えるとはいえn」 ?!?!(localhostで立ててくれるんか...これならCDN使えば簡単なサイトくらいやったらiPadだけで楽に作れるやんけ.
私たちはどうして公式ドキュメントが読めないのか？ - Qiita
少しプログラミングを覚えてきた初学者が、さらに力をつけるために必要なのが公式ドキュメントを読むことだと思います。 公式ドキュメントには、日本語の記事には書かれていないような詳細な説明や、APIの使用方法、そしてリリースノートなど、実装には不可欠な情報が掲載されています。 しかし、公式ドキュメントが上手く読めずにつまづく人も多いのではないでしょうか？慣れていない人にとっては、技術について書かれたドキュメントを読むのは難しいものです。 この記事では、つまづいてしまう人が少しでも減るように、公式ドキュメントが読めない原因と対策をいくつか書いていきます。 公式ドキュメントとは この記事で言及している「公式ドキュメント」は、フレームワークやライブラリ、言語について、その公式組織が出している文書のことです。 具体的にはこのへん。 どうして公式ドキュメントが読めないのか 原因1. 公式ドキュメントを読む
日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜 - Qiita
はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ？ 「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと始めた企業も流行りが変わると今度はリーンだとか、今度は○○だといったように新しい方式を導入してみては失敗するところも珍しくありません。 アジャイル開発の専門家ですと名乗る人の話を聞いてみても、それが何なのか、けむにまかれたような説明をされてしまい、いまいち納
やめた方が良いコーディング・設計、アンチパターン - Qiita
Help us understand the problem. What is going on with this article? 目的 レビュー時にアーとなる、お話にならない設計をまとめていきたい。 自分のためというより、話が通じないレベルの設計を言語化したい。 プログラミング言語関係なく、WEBサービスを作る時の、コーディング・設計の基本アンチパターン集としてまとめたい。 こんなコーディングや設計をする人がいないと思うレベルの悪質度の高いもの、極力避けてほしい書き方・設計を、気づいたらここに記述していく。 前半は「リーダブルコード」を読めば十分に分かる話だと思うし、殆ど超当たり前のことしか書いてないつもりなので、HTML～リリースの章を読んでほしい。 コード憎んで人を憎まず、罪を憎んで人を憎まず 「コード憎んで人を憎まず」というが、まずはそれが罪だと感じてる人がいる事が分からないと
【新元号】改元のシステム改修で慌てるシステム屋は「無能」とのこと - Qiita
という記事を見ての職業プログラマ歴３年程度の若造の過剰反応です。 まとまっていないポエムのようなものなので、 こんなことあるんだなっていう程度に思っていただいたら幸いです。 作ったプログラムを保守しているとは限らない まずはこれが大前提。 「作ったやつが無能」だとか「あらかじめ予想していなかった人が問題」だとか、 いろいろ思うことは当然私にもないとはいいませんが、 そういうことは後続の人が云ってはいけないと思っています。 なぜそうなったかの原因究明は必要ですが、悪口を言うための究明なら時間の無駄でしかない。 考慮ができていない「おかしなプログラム」を直すのが我々保守の一端、おざなりにしてはいけない。 １か月でリリースは難しい そもそもプログラムに直接書き込まれていて、 なおかつオフラインで運用されているシステムが、全国各地にある場合にある場合、 たった１か月で「調査→修正→テスト→納品」で
正しさとGo - Qiita
はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGoの本体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上
30歳とベルリンの壁 - Qiita
「ex-KAYAC Advent Calendar 2018」の12日目の記事となります。 どんな記事を書くかまだあまり決まってなかったんですけど、今までのアドベントカレンダーの流れを見るとカヤックを辞めてからのキャリアの話が多いので、私もそういった感じで書こうと思います。 ではまず、ちょっとした自己紹介させてください。 カヤックではとんぴーと呼ばれていたカナダ人のプログラマーです。 日本に引っ越したのが22歳の時で、主にゲーム業界に働いてきました。カヤックに内定した時点で約３年ぐらいPerlやPHPでゲームバックエンド開発の経験者でした。 2015年から２年弱「僕らの甲子園！ポケット」のサーバーサイド・エンジニアとして働いていました。ずっとぼくポケチームに配属されたので社員紹介ページを見ても実績のところにそれしか出てこないんですけど、よかったら見てください。 それからドイツのベルリンに引
新卒からの質問をソシャゲっぽい仕組みにしたら捗った話 - Qiita
ディップ Advent Calendar の4日目です。 はじめに こんにちは。 ディップでUXデザインや速度改善、潤滑油などをやっている@ysktsunaです。 今回は自分のチームに新メンバーを受け入れた時に発生した悩みと、それをソシャゲ風に解決した方法について書きます。 読んでほしい人 先輩として若手（特に新卒）の面倒を見る人 こんな話ありませんか？ 仲間が増えた 僕らのチームに新たなデザイナーが参画しました。 ：新卒ちゃん（デザイナ見習い） ：僕（おっさん） ＜ 新しくチームに入りました！ よろしくお願いします！ ＜ こちらこそよろしく。分からないことは何でも聞いてね！ ＜ ありがとうございます！ たくさん質問しますね！ ＜ 遠慮なくどうぞ～。（素直そうで良い子だなぁ） 元気も良くチームにも馴染んでくれそうで安心していました。 質問してくれた ＜ すいません、ここについて分からないん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術広報のカレンダー | Advent Calendar 2022 - Qiita
