タグ

関連タグで絞り込む (315)

タグの絞り込みを解除

developmentに関するkenjiro_nのブックマーク (789)

  • 実行中でのコールスタックの取得と表示 - 千里霧中

    メモ用。デバッグ等で有用なコールスタックはgdbなどの各種デバッガで取得できるけれど、実行中にアプリケーション内で取得したい場合がある。 それはglibcが使えるならbacktrace()、backtrace_symbols()で実現できる。 例えば下記のコード: #include <stdio.h> #include <execinfo.h> void hoge1(void) { size_t i; void *trace[128]; char **ss_trace; size_t size = backtrace(trace, sizeof(trace) / sizeof(trace[0])); ss_trace = backtrace_symbols(trace, size); if (ss_trace == NULL) { /*Failure*/ return; } /*例えば表示

    実行中でのコールスタックの取得と表示 - 千里霧中
  • ユーニックス総合研究所

    home archives c-error-stack-trace C言語のエラー処理: スタックトレースを作成する 作成日: 2021-09-13更新日: 2023-12-24 カテゴリ: C言語 C言語のエラー処理~スタックトレース編 C言語には例外機構がありません。 そのためスタックトレースなども出力できませんが、C言語らしくスタックを自作することでスタックトレースを実現することが可能です。 この記事ではC言語で自力でスタックトレースを出力するということをやってみたいと思います。 この方法はいわゆる「こういう方法もあるよ」というエラー処理の一例であり、ベターであるかどうかは皆さんが判断してください。 ちなみに私はプログラミング言語の開発でこのようなスタックトレース機構を使っています。 今のところ便利で、特にストレスはありません。 C言語のスタックトレースについて↓を見ていきたいと思い

  • GitHub - SeijiFujita/vscode-tag-jump: Tag-Jump for vscode

    kenjiro_n
    kenjiro_n 2023/10/27
    サクラエディタで多用してたタグテキストからのジャンプがVSCodeの本体機能にもあるかと思ったけど見つからなくてこういう拡張機能を見つけてしまった。
  • Python のロギングを完全に理解する - Qiita

    はじめに 言うまでもありませんがここでいう「完全に理解」はダニング=クルーガー的な意味で申し上げております。ご了承下さい。 今回の内容を3行でいうと Pythonのロギング(loggingパッケージ)の公式ドキュメントがどうも読みづらくてとっつきにくい とは言え実用的なものを作るにはロギングの理解は必須 そこで調べてみました。その内容。 と言うものになります。これを読めばとりあえずPythonのロギングについて何も知らない状態から、必要な最低限のことはわかったというところまで行けるものを目指しました。丁寧にやったので少し長くなりましたが内容は難しくありません。Pythonの実行環境がある方は実際にソースをコピペして動かしてみると理解が深まると思います。 今回使用したPythonのバージョン なぜ import logging をしてはいけないのか。 Pythonと言う言語はよくできた言語で

    Python のロギングを完全に理解する - Qiita
  • Eclipseでリモートデバッグする方法 - RAKUS Developers Blog | ラクス エンジニアブログ

    こんにちは、新卒2年目のEngawaです。 今回はサーバにデプロイしたWEBアプリをEclipseでリモートデバッグする方法を書いていきたいと思います。 はじめに 普段から開発を行っている際は、Eclipseのデバッグ機能を使い処理の流れや変数の値を確認しながら実装しているのですが、ローカル環境では実行できない部分(外部サービスと連携した後の処理とか)の実装では処理の流れや、変数には何が入っているかわからない上、動作確認もサーバにデプロイして確認しているのですが、エラーが出た時も詳細なエラー原因を探すのに苦労しました。 そこでサーバにデプロイしたWEBアプリをEclipseでリモートデバッグする方法を簡単にまとめてみました。 はじめに 設定 終わりに 参考 設定 まずはTomcatの設定からです。 起動シェルの以下の1文を変更 $SU - $TOMCAT_USER -c "${CATALI

    Eclipseでリモートデバッグする方法 - RAKUS Developers Blog | ラクス エンジニアブログ
  • エンジニアの職務経歴書 〜正しい魅力の伝え方〜 - Qiita

    はじめに 昨今の採用現場においてはソフトウェアエンジニアは売り手市場と言われ数年が経過していますが、2023年現在においても、デジタルトランスフォーメーションの加速により、これまでのIT企業の募集だけではなく、様々な企業がソフトウェアエンジニアを募集している状況にあると思います。 知り合いのリクルーターに話を聞くと、ここ最近米国のBigTech企業や、日初のベンチャー企業のレイオフが目立ちますが、それはごく一部であり、多くの企業では引き続きソフトウェアエンジニアの需要は最も高く、この先10年以上はこの高い需要は続くだろうと言っていました。 引用元: 【2023年最新】厳選!エンジニア採用に強い15の採用媒体比較~最新市場動向や採用戦略も徹底解説 - type 私自身が就職した10年数年前は望んでソフトウェアエンジニアに就く人は理系出身のプログラミング趣向が強い人ばかりという印象でしたが、

    エンジニアの職務経歴書 〜正しい魅力の伝え方〜 - Qiita
  • GitHub - joaomartiniano/MiniBug: Simple desktop issue tracker and to-do list, written in C# Windows Forms.

    kenjiro_n
    kenjiro_n 2023/01/23
    DBは使わず専用のJsonファイルで情報を登録している。
  • SQLを速くするぞ―お手軽パフォーマンス・チューニング

    このサイトでは、SQL を高速化するためのちょっとしたパフォーマンス・チューニングの技術を紹介します。と言っても、『プログラマのためのSQL 第2版』の受け売りがほとんどなので、このを読んでいただければ、稿を読む必要はありません。 最初に、パフォーマンス・チューニングに関する全体の方針を述べておくと、それはボトルネック(一番遅いところ)を改善することです。当たり前ですが、既に十分速い処理をもっと速くしたところで、システム全体のパフォーマンスには影響しません。従って「処理が遅い」と感じたら、最初にすることは、SQL やアプリの改修ではなく、「どこが遅いのか」を調査することです。いきなりあてずっぽうで改善をはじめても効果は出ません。医者が患者を診るとき最初にすることが検査であるのと同じです。病因が何であるかを突き止めてからでないと、正しい処方はできないのです。 その基を承知していただいた

  • 理由はいいから腕を磨け | ベイジの日報

    以前勤めていた会社はデザイナーが遠隔地にいたため、クライアントと直接会わないことが多かった。そのためディレクターがクライアントに直接話を聴き、その内容を社内に持ち帰ってデザイナーに伝える、という制作工程が一般的だった。 デザイナーの中には、それでも器用にデザインができてしまう人と、そうでない人がいた。そして後者のデザイナーからは、こんな声がよく上がっていた。 前段のインプットが十分ではないので作りにくい クライアントと直接話ができないので作りにくい この時ディレクターをやっていた私は、この意見に一理あると思った。 そこで、前段の設計資料をサマリーせずにフルで共有したり、オリエンをより丁寧にしてみたり、クライアントとの打ち合わせに同席してもらう機会を設けるようにした。 結果どうなったかといえば、変わらなかった。なぜなら、デザインのクオリティが低かったのは、インプットやクライアントと直接会うか

    理由はいいから腕を磨け | ベイジの日報
  • ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場

    ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場 Dockerコンテナの技術を用いることで、プログラミング言語のランタイムやライブラリ、ミドルウェアなどの開発環境一式を比較的容易に導入することが可能になりました。 ただしDockerコンテナにもファイルシステムのオーバーヘッドなどがあり、Dockerコンテナ内の開発環境ではコンパイルなどに時間がかかってしまう場合があったと開発ツールベンダのJetpack Technologiesは自社の経験から指摘します。 そこで同社がオープンソースで開発しているのが「Devbox」です(ちなみにマイクロソフトによる仮想化された開発環境の「Dev box」とは名前は似ていますが別のものです)。 Devboxは、ローカル環境上に分離した環境を用意しそこで開発環境を構築可能にしつつ、Do

    ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場
  • 仕事力と技術力と不安に関する雑文

    先日「育児など家庭の色々があって自分の時間が確保できなくなった。技術力を高めるための勉強ができなくて不安。」みたいな話を聞いた この悩みの直接的な解決方法としては先人の様々な体験談および対策みたいなものが世に出回っているからご家庭の状況に応じて参照すればいい思う 子育てと開発を両立するコツは「無理をしないこと」。パパ/ママエンジニアの働き方とは 子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには ITエンジニアと子育てと勉強と それよりも「技術力を高めるための勉強ができなくて不安」という点が個人的には気になった 技術力とは何か?技術力が高くないとなぜ不安なのか?みたいな話 技術力は特に明確な定義があるわけではない 例えば著名なOSSにコミットしているとか低レイヤーのプロトコルやインフラをバリバリ実装してるとか競プロで上位勢だとか、挙げ始めたらキリがなく、そ

    仕事力と技術力と不安に関する雑文
  • GitHub - dev-jan/no-bug: Bugtracking Platform based on PHP and MySQL

  • GitHub - php/web-bugs: The PHP Bugtracking System

  • Effectiveさお

    « [Android] Hyper-Vで使うVisual Studio Emulator for Androidの最初の一歩 どうもうまくAndroidエミュレータが動かない… いわゆる ADV Manager をつかって、Androidをエミューレートしたいのですが なぜかうまく起動しない… 環境 Windows10 x64 Visual Studio 2017 Android SDK Managerをよく見てみると、HAXM installer が “Not compatible with Windows” となっています ふむ… 無理矢理 HAXM のインストーラーをダウンロードしてきても、こんな感じでエラー This computer does not support Intel Virtualization Technology (VT-x) or it is being exc

  • 約束は開発を遅らせる - Mitsuyuki.Shiiba

    観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな?」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない?もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは

    約束は開発を遅らせる - Mitsuyuki.Shiiba
  • Bugs - Simple Open Source Bug Tracking Tool

  • GitHub - pixeline/bugs: Simple Issue Tracking for Teams. Built in Laravel 3 (php/mysql)

  • 日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ

    私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日なので日側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この2つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日だとしょっちゅうです。日のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか?いくつかの事例を通じてだんだん見えてきたことは1つのことをこなすための「物量」が違うということです。

    日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ
  • 森羅万象に「いいね」するためのデータ構造

    Kaigi on Rails 2022 にて『森羅万象に「いいね」するためのデータ構造』の発表をしました。 https://kaigionrails.org/2022/talks/pndcat/ ===概要=== サービス開発をしていると「いいね」の実装に対面することは多いでしょう。例えば EC サービスの場合、商品へのいいね、クチコミへのいいね、ブランドへのいいねなど、いろいろな対象に「いいね」をするケースが考えられます。さらには、ログインユーザーの「いいね」と、非ログインユーザーの「いいね」を作ることもあるかもしれません。 しかし、あらゆるものに「いいね」できるシステムを作るのは容易ならざることです。普通に実装するだけでは関連するコードは肥大化し、データベースのテーブルもどんどん増えていくばかりです。 似ているけど少し違う「いいね」を実装するにあたって、失敗してしまったデータ設計、そこ

    森羅万象に「いいね」するためのデータ構造
  • ほんまに一対多でええんか?

    こんにちは。株式会社プラハCEOの松原です。 今日は「ほんまに一対多でええんか?最初から多対多テーブルにしておいて備える方法もあるよ」というDB設計周りの話について書いてみます 一対多が多対多になる時に備える こういうユースケースに直面した時・・・ ユーザーは記事を複数作成できる 脊髄反射的にこういうテーブル構成が採用されるのを見かけます 「記事を作成するユーザーは一人なんだからこれで問題ないのでは?何が言いたいの?言いがかり?そういうの人として恥ずかしくない?」と思われるかもしれませんが、後々サービスの性質が変わって 複数ユーザーで記事を共同作成できる というユースケースが加わった時には中間テーブルを新規作成して既存データを移し替えるようなDBのマイグレーション作業が必要になります 最初から中間テーブルにしておくパターン もしauthorという中間テーブルを作ってarticle_id

    ほんまに一対多でええんか?