OSC Enterprise.2015での講演資料です。 JobSchedulerの概要・特長の紹介です。
Job schedulerを活用したoperations as codeの世界
OSC Enterprise.2015での講演資料です。 JobSchedulerの概要・特長の紹介です。
Jenkins 2を使った究極のpipeline ~ 明日もう一度来てください、本物のpipelineをお見せしますよ ~
Jenkins 2を使った究極のpipeline ~ 明日もう一度来てください、本物のpipelineをお見せしますよ ~ This document contains code for a Jenkins pipeline that defines stages for compiling, testing, packaging, deploying, and smoke testing a build. It also contains code to send notifications to Typetalk if the build fails. Additional code shows how to fetch pull request branches from a Git remote and check if a pull request is open for a g
【2024年最新】スマホでプログラミングができるアプリ12選
Progate Progateは、イラスト中心のスライド形式でプログラミングを学べるアプリです。学習の中で実際にコードを書くことができるので、実践的なスキルを身につけることができます。100以上の国で使われていて、利用者数は300万人以上の人気アプリです。 HTMLやCSSはもちろん、SQLやPythonなど15種類のプログラミング言語が学べます。環境構築が不要なため、簡単に始めることができます。初級は無料で、入門から基本編は月額990円〜となっています。 Progateのダウンロードはこちら（iOS） Progateのダウンロードはこちら（Android） 言語別の学習方法に関して詳しく知りたい方は、以下の記事をご覧ください。 Javaの勉強方法｜独学で入門するための学習のコツとステップアップの流れ SQLの勉強方法｜初心者向けに本、入門サイト、学習アプリなどの勉強法を紹介 Kotlin
シェルスクリプトの処理境界が鮮明になる「名前付きブロック記法」なるものを考えてみた
シェルスクリプトは長くなると処理の境界が不鮮明になりがち。 コメントで処理の境界を表現する工夫はよく見かけるが、もっと良い方法はないか考えてみた。 :コマンド、&&演算子、複合コマンド()や{}を組み合わせて書くと、処理の境界線がはっきりする。
正規表現：悪い表現、いい表現、最良の表現 | POSTD
わずかな文字がいかにしてパフォーマンスに大きな違いを生めるかというお話 正規表現は、私たち開発者がことあるごとに駆使する呪文のようなものですが、私たちはそれをどんな時も巧みに使いこなしていると言えるでしょうか。正規表現は繊細で精密な言語です。入念な慎重さで記述してやれば、ボウリングで一瞬にして完璧なストライクを取るような強力なテキストとなり得ます。 しかし、正規表現が精密さに欠ける状態で投げ出されると、さながら酔っ払いがよろよろとつまずきながらテキストの上を歩くがごとく、そのボールはぎこちなくボウリングのレーンを転がり、ピンを1つか2つ倒すだけで終わってしまうのです。 これら2つの正規表現の違いは何なのか。何がいい表現と悪い表現を分けるのか。正規表現に素晴らしい力を与えるメカニズムを、この投稿で明かしてみようと思います。効果的な表現とそうでない表現との大きな違いをきっと分かってもらえるはず
WPF4.5入門 その51 「リソース」 - かずきのBlog@hatena
ここでは、リソースについて説明します。WPFのコントロールには、ResourceDictionary型のResourcesというプロパティが定義されています。ResourceDictionaryクラスの中には、画像・文字列・オブジェクトなど様々なものを名前をつけて保持することが出来ます。そして、保持しているリソースにはXAMLやプログラムから参照して使うことが出来ます。 リソースの定義 リソースの定義は、通常WindowやAppクラスのResourcesプロパティに定義します。以下にApp.xamlにブラシのリソースを2つ定義する例を示します。 <Application x:Class="ResourceSample01.App" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http:
早く知っておけば良かったrailsの技 | dev.wan.co
rails 自分が rails をさわり始めたときはバージョン1からバージョン2に変わるあたりだったのですが、バージョン2が出た年を振り返るとなんと2007年でした。 月日の流れが速い事に驚く中、早く知ってたら良かったのになぁって事をつらつらとまとめてみました。 最近 rails さわり始めてみたよ！って方の参考になれば良いなと思います。 今回は便利な gem とかではなく、素のrailsで出来ることを挙げています。 ちなみにバージョンは以下の環境です。 About your application's environment Ruby version 2.1.3-p242 (x86_64-darwin14.0) RubyGems version 2.2.2 Rack version 1.5 Rails version 4.1.8 rails new したときの app 以下のディレクトリ
Recruit Tech Blog | 株式会社リクルート
株式会社リクルート エンジニアコース新人研修の内容を公開します！（2025年度版） 2025.08.28 新人研修
Ruboto
Ruby support can be added to any modern Android application by adding JRuby as a dependency. The Ruboto project aims to add some additional sample code to make the integration between Java, Ruby, and the Android platform a pleasant developer experience. The Apps created thereafter depend on JRuby (jruby-jars) at runtime to provide full access to Android's Java APIs. Installation is straight-forwar
Web Application の validation はどのレイヤーでかけるべきか - tokuhirom's blog
Web Application の validation はどのレイヤーでかけるべきか 数年前にも同じことかいた気がするけど、最近の状況にあわせてかいてみる。 途中で面倒になってきて説明が雑になっている点をご容赦ください。 言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。 この表題は、よく話題にあがるところなのだが、理想論としては Model, Controller, Client side のいずれにおいてもきっちりと validation を行うことがのぞましい。 しかし、実際にはなかなか面倒である。ということで、どこをはぶくかというと Controller における Validation であろう。 ユーザ
Webプログラミング素人が利用者9万人のmixiアプリを作るまで - 毒蛇は急がない
はじめに 最近、 文系ド素人がmixiアプリを開発〜リリースするまでのまとめ http://d.hatena.ne.jp/kazu0620/20100412/1271071223 というエントリーが話題になりましたね。自分もwebプログラミング素人でmixiアプリを作ってみたので、ちょっと便乗して、自分がmixiアプリを作るまでのプロセスをまとめてみました。 これからアプリを作る人の参考になれば幸いです。 kazu0620さんは、個人で作っていたみたいですが、自分は会社で作りました。会社といっても、自分含め従業員数3人の超零細企業でフリーランスの延長線上みたいなかたちでやっている会社ですが。 ちなみに会社のサイトはこちら。 作ったアプリ 「ふしぎな生き物 ふにゃもらけ」 http://mixi.jp/run_appli.pl?id=9443 リリース日：3/23 実質開発期間：8ヶ月 週間
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
Loading...
Amazon.co.jp: Effective Objective-C 2.0: Matt Galloway (著), 長尾高弘 (監修): 本
