-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.xml
More file actions
36 lines (29 loc) · 2.14 KB
/
index.xml
File metadata and controls
36 lines (29 loc) · 2.14 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Abimael Martínez</title>
<link>http://abijr.com/</link>
<description>Recent content on Abimael Martínez</description>
<generator>Hugo -- gohugo.io</generator>
<language>en-US</language>
<lastBuildDate>Sun, 30 Apr 2017 21:19:59 -0500</lastBuildDate>
<atom:link href="http://abijr.com/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>Golang and the Next-Gen Build Tools</title>
<link>http://abijr.com/blog/golang-and-the-next-gen-build-tools/</link>
<pubDate>Sun, 30 Apr 2017 21:19:59 -0500</pubDate>
<guid>http://abijr.com/blog/golang-and-the-next-gen-build-tools/</guid>
<description>The three general build systems from the big players. Bazel by Google, Pants by Twitter and Buck by Facebook, all attempt to allay the problems plaguing build system since time immemorial. They are all based on the internal build system from Google, Blaze, and as such, they are almost identical in features. They improve on the correctness, speed and modularity of the builds with features such as sandboxed builds, caching of targets, and namespacing of build modules.</description>
</item>
<item>
<title>A Continuous Deployment Workflow Draft</title>
<link>http://abijr.com/blog/a-continuous-deployment-workflow-draft/</link>
<pubDate>Sun, 03 May 2015 19:34:35 -0500</pubDate>
<guid>http://abijr.com/blog/a-continuous-deployment-workflow-draft/</guid>
<description>This is a workflow draft for the development and deployment of the myriad of services and applications used at my current workplace.
The Problem(s) An overview of the current situation.
Most applications and web services are hand installed or developed directly in production servers. There is no easy way to deploy to production servers.
When applications/services crash, they crash&hellip; hard. No graceful failures, reason being that, there is only one instance of each application/service.</description>
</item>
</channel>
</rss>