<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://brokenco.de//feed/by_tag/lookout.xml" rel="self" type="application/atom+xml" /><link href="https://brokenco.de//" rel="alternate" type="text/html" /><updated>2026-05-03T00:12:50+00:00</updated><id>https://brokenco.de//feed/by_tag/lookout.xml</id><title type="html">rtyler</title><subtitle>a moderately technical blog</subtitle><author><name>R. Tyler Croy</name></author><entry><title type="html">Four years of Lookout</title><link href="https://brokenco.de//2015/04/26/four-years-lookout.html" rel="alternate" type="text/html" title="Four years of Lookout" /><published>2015-04-26T00:00:00+00:00</published><updated>2015-04-26T00:00:00+00:00</updated><id>https://brokenco.de//2015/04/26/four-years-lookout</id><content type="html" xml:base="https://brokenco.de//2015/04/26/four-years-lookout.html"><![CDATA[<p>Four years ago today I started work at <a href="http://lookout.com">Lookout, Inc.</a>,
embarking on the longest journey of my career to date. I had left
<a href="https://en.wikipedia.org/wiki/Apture">Apture</a> frustrated with our inability to
grow the product and engineering team, but with pockets full of experience at
building and deploying service-oriented applications “my way.” At the time
Apture was literally down the block from Lookout, so on a Friday I left Apture
and the following Monday I took my same commute in to Lookout. What I wasn’t
able to get at Apture, I found at Lookout.</p>

<p>As one of the first fourty or so employees, I’ve been fortunate enough not only
to see an organization grow up, but also to play an important role in that growth.</p>

<p>To give you an idea of what four years looks like, here are the initiatives I’m
most proud to have worked on:</p>

<ul>
  <li>Deploying Jenkins/Git/Gerrit, cementing continuous integration and code
review into the development process.</li>
  <li>Building a large Selenium test suite to help qualify releases of the
consumer web application</li>
  <li>Moving the consumer backend web application from two week to daily
deployments, driving a 33% deployment failure rate down to 3%.</li>
  <li>Leading the team which built and delivered an entirely new version of the
consumer web application</li>
  <li>Leading the team which built and delivered the Small and Medium Business
product, one of the first service oriented products delivered at Lookout,
based on 5 discrete services.</li>
  <li>Leading the team (same as the last team) which built and delivered the beta
product for what has been since renamed to <a href="https://www.lookout.com/mobile-threat-protection">Mobile Threat
Protection</a>, composed of a
number of discrete services, built on newly deployed infrastructure components
such as <a href="http://kafka.apache.org">Apache Kafka</a> and <a href="http://storm.apache.org">Apache
Storm</a>.</li>
  <li>Helping hire over 30 new members of Lookout Engineering.</li>
  <li><a href="http://hackers.lookout.com">hackers.lookout.com</a> and <a href="https://github.com/lookout">Lookout on
GitHub</a>, pushing open source engagement as a
top-level engineering goal.</li>
</ul>

<p>With the founding of my current team, Core Systems, we’ve finally reached a
size to merit this specialization in infrastructure engineering which is of
particular interest to me.</p>

<p>I’ve now been at Lookout for longer than any previous employer. It has
definitely been a roller coaster, but it is still one I don’t intend on leaving
any time soon.</p>]]></content><author><name>R. Tyler Croy</name></author><category term="lookout" /><category term="personal" /><summary type="html"><![CDATA[Four years ago today I started work at Lookout, Inc., embarking on the longest journey of my career to date. I had left Apture frustrated with our inability to grow the product and engineering team, but with pockets full of experience at building and deploying service-oriented applications “my way.” At the time Apture was literally down the block from Lookout, so on a Friday I left Apture and the following Monday I took my same commute in to Lookout. What I wasn’t able to get at Apture, I found at Lookout.]]></summary></entry><entry><title type="html">First London, then to Brussels</title><link href="https://brokenco.de//2015/01/07/london-brussels-fosdem.html" rel="alternate" type="text/html" title="First London, then to Brussels" /><published>2015-01-07T00:00:00+00:00</published><updated>2015-01-07T00:00:00+00:00</updated><id>https://brokenco.de//2015/01/07/london-brussels-fosdem</id><content type="html" xml:base="https://brokenco.de//2015/01/07/london-brussels-fosdem.html"><![CDATA[<p>It’s <a href="http://fosdem.org">that time again</a>! FOSDEM 2015 is quickly approaching
and just like <a href="/2014/01/05/another-february-in-yurp.html">last year</a> I’m
thrilled to be going again. This year I will be making a stop-over for a few
days in London (Jan 24-28th) to visit the <a href="http://lookout.com">Lookout</a> London
office before heading towards Brussels. If you’re interested in drinking a beer
in either location, ping me via <a href="https://twitter.com/agentdero">twitter</a> or
email.</p>

<p>I did the math in my head yesterday and this year will be the <strong>fifth</strong> year
that I’ve attended FOSDEM: 2005, 2012, 2013, 2014 and 2015. This will be my
fourth year helping organize a <a href="https://jenkins-ci.org">Jenkins</a> stand, my third year
organizing the <a href="https://fosdem.org/2015/schedule/track/testing_and_automation/">Testing and Automation
devroom</a> and my
<strong>first</strong> year organizing a <a href="https://fosdem.org/2015/schedule/track/ruby/">Ruby
devroom</a>.</p>

<p>Between the schedules for the Testing/Automation and the Ruby devroom,
I am thrilled with the amount of great content that I’ve been able to help
bring to FOSDEM. But that just covers <em>two</em> rooms, between the main tracks
and 40 devrooms, words cannot describe the sheer volume of great content and
great people who will be present.</p>

<p>If you’re not able to make it to FOSDEM,
<a href="http://video.fosdem.org/">video.fosdem.org</a> has most of last year’s talks and
will have archived recordings of the 2015 talks as well.</p>

<p>If you <strong>can</strong> make it to FOSDEM, come say hello!</p>]]></content><author><name>R. Tyler Croy</name></author><category term="fosdem" /><category term="fosdem2015" /><category term="lookout" /><summary type="html"><![CDATA[It’s that time again! FOSDEM 2015 is quickly approaching and just like last year I’m thrilled to be going again. This year I will be making a stop-over for a few days in London (Jan 24-28th) to visit the Lookout London office before heading towards Brussels. If you’re interested in drinking a beer in either location, ping me via twitter or email.]]></summary></entry><entry><title type="html">Open Hacksgiving 2014 Live Blog</title><link href="https://brokenco.de//2014/11/24/hacksgiving-live-blog.html" rel="alternate" type="text/html" title="Open Hacksgiving 2014 Live Blog" /><published>2014-11-24T00:00:00+00:00</published><updated>2014-11-24T00:00:00+00:00</updated><id>https://brokenco.de//2014/11/24/hacksgiving-live-blog</id><content type="html" xml:base="https://brokenco.de//2014/11/24/hacksgiving-live-blog.html"><![CDATA[<p>For the past three years at <a href="http://hackers.lookout.com">Lookout</a> we’ve hosted
an event called “<a href="http://hacksgiving.com">Hacksgiving</a>.” Historically the event
has been focused on cool hacks typically oriented around projects or ideas that
are internal to Lookout. The first year, for example, a colleague and I
prototyped the messaging system that would power our <a href="https://www.lookout.com/enterprise-mobile-security">business
product</a> the following
year. Another group of hackers created the precursor to our <a href="http://techcrunch.com/2012/10/09/lookouts-signal-flare-helps-you-find-lost-android-phones-that-have-dying-batteries/">signal
flare</a>
feature that same year (hif I’m remembering correctly).</p>

<p>This year I figured I’d try something different: <strong>Open Hacksgiving</strong>. I’m going to
spend the hackathon hacking on open source projects and updating the status of
those projects here.</p>

<p>I’ll also be lurking in <a href="https://gitter.im/lookout/hacksgiving.com">this gitter.im
chat</a> if you’re feeling bored or
want to suggest some issues from GitHub for me to hack on.</p>

<p><a name="updates"></a></p>
<h2 id="updates">Updates</h2>

<ul>
  <li>(13:17 PDT) Concluding the live blogging, and am going to spend some time
writing up docs and what not. Happy Hacksgiving!</li>
  <li>(12:09 PDT) Further testing on different machines exposed <a href="https://github.com/ratpack/ratpack/issues/503">this bug
(#503)</a> in Ratpack, forcing a
requirement of JDK8 :(</li>
  <li>(11:22 PDT) Cut the
<a href="https://github.com/rtyler/offtopic/releases/tag/v0.1.0">v0.1.0</a> release of
Offtopic!. Threw an installation of it on my workstation to display a big
stream of events in the offics</li>
  <li>(10:29 PDT) Verified that Offtopic! and the multipass feature works for
monitoring a number of topics in a Real Usecase™ at <a href="http://lookout.com">Lookout</a>.</li>
  <li>(09:12 PDT) Coffee made, mail read, picking up where I left off last night
with some more interesting functionality in Offtopic.</li>
  <li>(08:30 PDT) Traveling back to the office with more ideas kicking around in my
head on how to make <a href="https://github.com/rtyler/offtopic">Offtopic</a> more
gooder.. Turns out testing something that depends on Zookeeper and Kafka
being available isn’t that great on the bus</li>
  <li><strong>Day Two</strong></li>
  <li>(23:31 PDT) Not much more cogent thought going into my hacking tonight,
heading home</li>
  <li>(23:23 PDT) Hacked some pretty start/stop buttons into the web UI for
Offtopic to connect/disconnect the websocket.</li>
  <li>(23:01 PDT) Manage to implement grepping/filtering messages coming through to
Offtopic</li>
  <li>(22:19 PDT) Implemented wildcards, hurrah!</li>
  <li>(21:46 PDT) Starting to figure out topic wildcards to Offtopic!</li>
  <li>(21:08 PDT) Finished watching The Fifth Element with some coworkers, managed
to <a href="https://github.com/rtyler/offtopic/issues/7">combining Kafka topic
streams</a> implemented!</li>
  <li>(17:53 PDT) Finished up a few more
<a href="https://github.com/rtyler/offtopic">Offtopic!</a> tasks. Feeling confident in
my ability to figure out problems with Groovy now</li>
  <li>(17:35 PDT) Recovering from a distraction of real work over another beer.
Managed to stave off responsibility for another day or two.</li>
  <li>(16:34 PDT) Beer finished, still chugging away on “Offtopic!”, refactoring a
lot of the messy code that I wrote in anger yesterday</li>
  <li>(15:51 PDT) Planned a bit of work on
<a href="https://github.com/rtyler/offtopic">Offtopic</a> after discussing some useful
features with coworkers who also want more visibility into Kafka streams</li>
  <li>(15:36 PDT) Moved downstairs to the kitchen area at Lookout, poured myself a
beer to celebrate conquering some Gradle work.</li>
  <li>(15:01 PDT) Managed to get a
<a href="https://bintray.com/jruby-gradle/plugins/jruby-gradle-war-plugin/0.1.3/view">v0.1.3</a>
 release of the
 <a href="https://github.com/jruby-gradle/jruby-gradle-war-plugin">jruby-gradle-war-plugin</a>
 with all my good fixes. Demo app published as
 <a href="https://github.com/rtyler/hellowarld">hellowarld</a></li>
  <li>(14:46 PDT) Finally figured out my issue, it turns out that using Vim to
inspect the <code class="language-plaintext highlighter-rouge">.war</code> files was a stupid idea because Vim caches the buffers for
files within the Zip file, deceiving me into thinking my changes weren’t
actually working! <strong>smashes keyboard</strong></li>
  <li>(13:45 PDT) Had to abandon my previous approach of getting a bundled
<code class="language-plaintext highlighter-rouge">web.xml</code> inserted into the war file. Somehow I’m now generating a <code class="language-plaintext highlighter-rouge">.war</code>
 file with a <code class="language-plaintext highlighter-rouge">web.xml</code> file that doesn’t match anything in my current source
 tree. GHOST XMLS</li>
  <li>(12:23 PDT) Thanks to <a href="http://stackoverflow.com/questions/4317035/how-to-convert-inputstream-to-virtual-file#16028522">this stackoverflow
post</a>
I’ve at least got a path forward to fixing the aforementioned issue of
bundling resources inside my Gradle plugin. Somehow I broke my zips somewhere
around here: <code class="language-plaintext highlighter-rouge">&gt; java.util.zip.ZipException: too many length or distance
symbols</code></li>
  <li>(11:43 PDT) Slowing down on progress, trying to resolve <a href="https://github.com/jruby-gradle/jruby-gradle-war-plugin/issues/1">this
issue</a>,
which requires Gradle plugin hacking that I’ve not done before</li>
  <li>(11:16 PDT) Managed to get a Gradle-built version of
<a href="https://github.com/rtyler/hellowarld">hellowarld</a> loaded and executing
properly inside of Jetty 8</li>
  <li>(10:54 PDT)
<a href="https://github.com/jruby-gradle/jruby-gradle-war-plugin">jruby-gradle-war-plugin</a>
properly building executable <code class="language-plaintext highlighter-rouge">.war</code> files with embedded gems.</li>
  <li>(10:26 PDT) Unblocked coworker with some Gradle hacking, back to my own
hackz0ring!</li>
  <li>(09:59 PDT) Context-switch to help another developer use
<a href="https://github.com/jruby-gradle">jruby-gradle</a> for their hackathon project.</li>
  <li>(09:25 PDT) Break-time over, back to baking <code class="language-plaintext highlighter-rouge">.war</code> files with
<a href="http://gradle.org">Gradle</a></li>
  <li>(09:15 PDT) Found some breakfast burritos downstairs, burrito break!</li>
  <li>(08:30 PDT) Writing the live blog post. Coffee made,
<a href="https://github.com/jruby-gradle/jruby-gradle-war-plugin">jruby-gradle-war-plugin</a>
selected as the first project to tinker with.</li>
</ul>]]></content><author><name>R. Tyler Croy</name></author><category term="lookout" /><category term="hacksgiving" /><category term="lookouteng" /><category term="opensource" /><summary type="html"><![CDATA[For the past three years at Lookout we’ve hosted an event called “Hacksgiving.” Historically the event has been focused on cool hacks typically oriented around projects or ideas that are internal to Lookout. The first year, for example, a colleague and I prototyped the messaging system that would power our business product the following year. Another group of hackers created the precursor to our signal flare feature that same year (hif I’m remembering correctly).]]></summary></entry><entry><title type="html">About the Lookout Hackers Blog</title><link href="https://brokenco.de//2012/05/22/lookout-hackers.html" rel="alternate" type="text/html" title="About the Lookout Hackers Blog" /><published>2012-05-22T00:00:00+00:00</published><updated>2012-05-22T00:00:00+00:00</updated><id>https://brokenco.de//2012/05/22/lookout-hackers</id><content type="html" xml:base="https://brokenco.de//2012/05/22/lookout-hackers.html"><![CDATA[<p>I’ve neglected cross-posting some of the articles I’ve written over the past
month or so for the newly inaugurated <a href="http://hackers.mylookout.com/">Lookout Hackers
blog</a>. The generally idea of the Hackers blog is
to give Lookout Engineering a bit clearer of a voice and an avenue to publish
blog posts on things that are nitty-gritty and technical.</p>

<p>A couple of the posts I’ve written which may interest you are:</p>

<ul>
  <li>
    <p><a href="http://hackers.mylookout.com/2012/04/integration-testing-with-foreman">Integration Testing with Foreman</a></p>

    <p><em>At Lookout we find ourselves building more and more APIs and backend
  services these days. Naturally we would like to be certain that everything will
  work fine and dandy once it has been deployed. The reality of building out a
  service-oriented architecture is that you not only have to expect failure to
  happen, you have to plan and test for it.</em></p>
  </li>
  <li>
    <p><a href="http://hackers.mylookout.com/2012/05/continuous-deployment-for-gems">Continuous Deployment for Ruby Gems</a></p>

    <p><em>With the above workflow and these conventions in place, we’ve reaped a
  couple of benefits, the most obvious one has been the severely reduced time it
  takes for new gems to be created and incorporated into production systems.
  At a higher level, we’ve gained more confidence in our gems with this emphasis
  on testing, traceability and code review baked into the process from the start.</em></p>
  </li>
</ul>

<p>The blog is still fairly young, and we’re getting more developers used to
writing blog posts for it. You can subscribe to the <a href="http://feeds.feedburner.com/LookoutHackersBlog">atom feed
here</a> or just follow
<a href="https://twitter.com/lookouteng">@LookoutEng</a> on Twitter.</p>]]></content><author><name>R. Tyler Croy</name></author><category term="lookout" /><category term="ruby" /><category term="devops" /><summary type="html"><![CDATA[I’ve neglected cross-posting some of the articles I’ve written over the past month or so for the newly inaugurated Lookout Hackers blog. The generally idea of the Hackers blog is to give Lookout Engineering a bit clearer of a voice and an avenue to publish blog posts on things that are nitty-gritty and technical.]]></summary></entry><entry><title type="html">How can you live without Graphite?</title><link href="https://brokenco.de//2011/06/09/how-can-you-live-without-graphite.html" rel="alternate" type="text/html" title="How can you live without Graphite?" /><published>2011-06-09T00:00:00+00:00</published><updated>2011-06-09T00:00:00+00:00</updated><id>https://brokenco.de//2011/06/09/how-can-you-live-without-graphite</id><content type="html" xml:base="https://brokenco.de//2011/06/09/how-can-you-live-without-graphite.html"><![CDATA[<p>An interesting part of the hiring process at
<a href="https://www.mylookout.com/about/jobs">Lookout</a> is the candidate presentation.
The presentation is meant to introduce the individual to the entire company
while giving them an opportunity to wax poetic on a topic the person is passionate
about.</p>

<p>As part of my interview process, I decided to present my work with
<a href="http://graphite.wikidot.com">Graphite</a>, a real-time scalable “analytics” tool.</p>

<p>I place the word “analytics” in quotes because Graphite itself is really a tool
for storing an <em>enormous</em> number of data points in, whether it be “analytics”
in the product sense of the word, machine metrics, performance counters, or
any other data point that can be recorded and graphed over time.</p>

<p>While at <a href="http://www.apture.com">Apture</a>, I deployed and utilized Graphite
primarily for performance monitoring and profiling. Within days of it being
deployed, I remember <a href="http://twitter.com/kansteven">Steven</a> turning to me as we
looked over some performance numbers saying “what were we doing <em>before</em>?!”</p>

<p>Flying blind, that’s what.</p>

<p>I can’t recommend Graphite highly enough, but at least one should have a
similar system in place to give the team some level of feedback about <strong>how</strong>
an application is actually performing in production.</p>

<p>My presentation alone isn’t terribly informative by itself, but has some pretty
screenshots and graphs. There are no associated notes with the PDF as I felt
comfortable and confident enough discussing Graphite that I ad-libbed my
commentary.</p>

<p><strong><a href="HTTP://strongspace.com/rtyler/public/Graphite%20is%20the%20new%20Ganglia.pdf">Graphite is the new Ganglia.pdf</a></strong></p>]]></content><author><name>R. Tyler Croy</name></author><category term="ganglia" /><category term="graphite" /><category term="lookout" /><category term="apture" /><category term="presentation" /><summary type="html"><![CDATA[An interesting part of the hiring process at Lookout is the candidate presentation. The presentation is meant to introduce the individual to the entire company while giving them an opportunity to wax poetic on a topic the person is passionate about.]]></summary></entry><entry><title type="html">Playing with pointers, and fire</title><link href="https://brokenco.de//2011/05/20/playing-with-pointers-and-fire.html" rel="alternate" type="text/html" title="Playing with pointers, and fire" /><published>2011-05-20T00:00:00+00:00</published><updated>2011-05-20T00:00:00+00:00</updated><id>https://brokenco.de//2011/05/20/playing-with-pointers-and-fire</id><content type="html" xml:base="https://brokenco.de//2011/05/20/playing-with-pointers-and-fire.html"><![CDATA[<p>It is a little (unknown) fact that my first job as a software developer was
writing C code, for the <a href="http://nis.tamu.edu/">network group</a> at <a href="http://www.tamu.edu">Texas A&amp;M
University</a>. Like most student developers, my work never
saw the light of day, mostly because I never finished it, but I did learn an
incredible amount working on my little project made for one.</p>

<p>I had never expected that 6 years later in my career, I’d somehow still be
dealing with some of the same issues, in the same crusty 30 year old language:
C. I feel I should note that every job that I’ve ever had, except <em>one</em>,
involved writing C code at some point, odd.</p>

<p><img src="/images/kitty_failure.jpg" alt="Lolcat smashes heap" title="Lolcat smashes heap" align="right" width="170" />
To be honest I’m both surprised and irritated by C’s longevity as a systems
language.  When I scan the landscape for the titans of modern web software I
see it <em>everywhere</em>. <a href="http://www.redis.io">Redis</a>,
<a href="http://www.nginx.org">Nginx</a>, <a href="http://www.python.org">Python</a>,
<a href="http://www.ruby-lang.org">Ruby</a>, <a href="http://dev.mysql.com">MySQL</a>,
<a href="http://httpd.apache.org">Apache</a>, <a href="http://haproxy.1wt.eu/">HAProxy</a> and the
list goes on and on. Don’t get me wrong, C is a very fast and suitable tool to
build all these services, it’s just so damn <strong><em>dangerous</em></strong> that I’m shocked
how much it’s still used.</p>

<p>My mind immediately goes to <a href="http://archive.adaic.com/intro/ada-vs-c/cada_art.html">this
study</a> that I had read
at some point regarding comparisons of development costs and defect rates
between <em>very</em> similar C and Ada projects. While the study is almost as old as
I am, it strikes a chord with me every time I am working on some C-based
projects.</p>

<p>Take <a href="https://github.com/antirez/redis/blob/unstable/src/sds.c">this code</a> from
the Redis code base for
example, which I recently had the pleasure of working with. I am aware that
<a href="https://github.com/antirez">Salvatore</a> is a brilliant hacker but this is
<em>madness</em>. If you cannot easily grok the code, I’ll clarify what this tiny
library does: in order to provide dynamically sizable strings in C, this code
will allocate a block of memory for a string that looks like this:</p>

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>0               9           N
+---------------------------+
| struct sdshdr |  char *   |
+---------------------------+
</code></pre></div></div>

<p>A little goofy, but easy to understand and deal with. <em>Except</em> for the fact that
the pointer that is passed around is to address <code class="language-plaintext highlighter-rouge">9</code> instead of <code class="language-plaintext highlighter-rouge">0</code>, meaning all
operations that work with the entire block perform pointer arithmetic to
calculate the appropriate starting address for the block. For example, here’s
the <code class="language-plaintext highlighter-rouge">sdsfree</code> implementation:</p>

<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>void sdsfree(sds s) { /* sds == char * */
    free(s - sizeof(struct sdshdr));
}
</code></pre></div></div>

<p>I have two reasons for picking on this specific code, and they were both in the
form of gnarly core dumps I’ve spent resolving the past couple days. If at
<strong>any point</strong> in your program you or anybody else accidentally passes a <code class="language-plaintext highlighter-rouge">char*</code>
into <em>any</em> of these SDS functions, your program will crash and there’s nothing
your compiler can do to save you from this. Since the <code class="language-plaintext highlighter-rouge">sds</code> is a <code class="language-plaintext highlighter-rouge">typedef</code> of
<code class="language-plaintext highlighter-rouge">char*</code> not only will you never see any compiler warnings, you won’t see any
warnings from static analysis tools either.</p>

<p>I’ve heard people say that one of the problems with C++ is that it gives you
too much rope with which to hang yourself. If that’s the case, C not only gives
the the rope but double-dog dares you to try to hang yourself with it.</p>

<p>Perhaps in another post I’ll detail how pointers and types are handled in Ada,
which I think is a major improvement of the C model without sacrificing speed.
I don’t mean to imply that everything that is written in C should <em>really</em> be
written in Ada, I just find the language’s solution to this problem to be
interesting. Instead of Ada, pick Java, Python, Scala, Ruby, D or any other
language that’s been developed in the post-K&amp;R world, they all have built on
top of the lessons learned from C’s short-comings.</p>

<p>It’s been almost 40 years since C was first introduced; that’s over two or three
generations of programmers hanging themselves.</p>

<hr />
<p><em>Disclaimer:</em> I actually <em>like</em> working on projects in C, it’s always an
interesting challenge, like starting arguments with my wife I have no chance of
winning.</p>

<hr />]]></content><author><name>R. Tyler Croy</name></author><category term="software development" /><category term="lookout" /><category term="c" /><category term="ada" /><summary type="html"><![CDATA[It is a little (unknown) fact that my first job as a software developer was writing C code, for the network group at Texas A&amp;M University. Like most student developers, my work never saw the light of day, mostly because I never finished it, but I did learn an incredible amount working on my little project made for one.]]></summary></entry><entry><title type="html">A month working at Lookout</title><link href="https://brokenco.de//2011/05/17/working-at-lookout.html" rel="alternate" type="text/html" title="A month working at Lookout" /><published>2011-05-17T00:00:00+00:00</published><updated>2011-05-17T00:00:00+00:00</updated><id>https://brokenco.de//2011/05/17/working-at-lookout</id><content type="html" xml:base="https://brokenco.de//2011/05/17/working-at-lookout.html"><![CDATA[<p>About a month ago I changed jobs, leaving <a href="http://www.apture.com">Apture</a> to
join a start-up in a completely different space: <a href="http://www.mylookout.com">Lookout,
Inc.</a>. While I won’t delve too deeply into my reasons
for leaving, my reasons for <em>joining</em> were almost entirely driven by the team.
I was fortunate enough to meet with <a href="http://twitter.com/dropalltables">Kevin</a>
and <a href="http://twitter.com/johnhering">John</a> (CTO and CEO respectively) through a
mutual friend and some time after that <a href="http://twitter.com/davegolombek">Dave
G.</a>, the tech lead for the server team. The
more people I met from Lookout, the more I wanted to work there.</p>

<p>Unlike both Apture and Slide, Lookout is a <a href="http://ruby-lang.org">Ruby</a> shop
which has presented a number of new and interesting challenges for me, most of
which I’ll enumerate as the months go on. At this point, I must say the Python
community has much that they/we could learn from subsections of the Ruby
community. There seems to be an underlying ethos amongst Ruby hackers to make
things simple and easier if possible, taking advantage of some of the unique
features of the language to acheive this.</p>

<p>When I first mentioned this on Twitter, I felt very flattered that multiple
people mentioned that they were “sure I would start up my thing after Apture.”
In my own opinion, I still have <strong>much</strong> to learn before I would feel confident
pitching potential investors and building a team from scratch. Founders are in
it for the long-haul, and as such I think they should be 100% committed to
making the product and team successful. I’m not there yet, but I’ll be there
soon.</p>]]></content><author><name>R. Tyler Croy</name></author><category term="lookout" /><category term="apture" /><summary type="html"><![CDATA[About a month ago I changed jobs, leaving Apture to join a start-up in a completely different space: Lookout, Inc.. While I won’t delve too deeply into my reasons for leaving, my reasons for joining were almost entirely driven by the team. I was fortunate enough to meet with Kevin and John (CTO and CEO respectively) through a mutual friend and some time after that Dave G., the tech lead for the server team. The more people I met from Lookout, the more I wanted to work there.]]></summary></entry></feed>