<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:media="http://search.yahoo.com/mrss/"><channel><title><![CDATA[source code - Binary Sludge]]></title><description><![CDATA[dredging the digital quagmire]]></description><link>https://www.binarysludge.com/</link><generator>Ghost 0.11</generator><lastBuildDate>Fri, 01 May 2026 06:46:26 GMT</lastBuildDate><atom:link href="https://www.binarysludge.com/tag/source-code/rss/" rel="self" type="application/rss+xml"/><ttl>60</ttl><item><title><![CDATA[Google's AngularJS Style Guide]]></title><description><![CDATA[<p>Google have published their internal <a href="https://google-styleguide.googlecode.com/svn/trunk/angularjs-google-style.html">AngularJS Style Guide</a>. It contains language and style rules, a basic naming convention (i.e. don't use $ as a variable prefix), test-driven recommendations (use Jasmine and Karma), a link to newly-published <a href="https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub">directory structure recommendations</a>, a <a href="https://github.com/angular/angular.js/wiki/Understanding-Scopes#wiki-JSproto">guide to scope and prototypal inheritance</a> and an ngInject example.</p>]]></description><link>https://www.binarysludge.com/2014/02/18/googles-angularjs-style-guide/</link><guid isPermaLink="false">34af64ce-4958-4276-901b-f21c5df36d5d</guid><category><![CDATA[Karma]]></category><category><![CDATA[Javascript]]></category><category><![CDATA[Programming]]></category><category><![CDATA[software engineering]]></category><category><![CDATA[source code]]></category><category><![CDATA[TDD]]></category><category><![CDATA[Unit Testing]]></category><category><![CDATA[AngularJS]]></category><dc:creator><![CDATA[Andrew Martin]]></dc:creator><pubDate>Tue, 18 Feb 2014 17:25:02 GMT</pubDate><content:encoded><![CDATA[<p>Google have published their internal <a href="https://google-styleguide.googlecode.com/svn/trunk/angularjs-google-style.html">AngularJS Style Guide</a>. It contains language and style rules, a basic naming convention (i.e. don't use $ as a variable prefix), test-driven recommendations (use Jasmine and Karma), a link to newly-published <a href="https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub">directory structure recommendations</a>, a <a href="https://github.com/angular/angular.js/wiki/Understanding-Scopes#wiki-JSproto">guide to scope and prototypal inheritance</a> and an ngInject example.</p>]]></content:encoded></item><item><title><![CDATA[High Performance Browser Networking]]></title><description><![CDATA[<p>Google web performance engineer <a href="http://www.igvita.com/">Ilya Grigorik</a> has put together the definitive tome on bleeding-edge, high speed web apps. The book is packed with information on performance optimization best practices for TCP, UDP, and TLS protocols, and explains unique wireless and mobile network optimization requirements:  </p>

<blockquote>How prepared are you to build</blockquote>]]></description><link>https://www.binarysludge.com/2014/01/31/high-performance-browser-networking/</link><guid isPermaLink="false">2a8205d1-24d2-451c-a66c-095b56f8c59e</guid><category><![CDATA[books]]></category><category><![CDATA[Chrome]]></category><category><![CDATA[Apache]]></category><category><![CDATA[HTTP Sessions]]></category><category><![CDATA[Javascript]]></category><category><![CDATA[linux]]></category><category><![CDATA[Mozilla Firefox]]></category><category><![CDATA[Programming]]></category><category><![CDATA[software engineering]]></category><category><![CDATA[source code]]></category><category><![CDATA[SSH]]></category><category><![CDATA[system adminstration]]></category><category><![CDATA[system architecture]]></category><dc:creator><![CDATA[Andrew Martin]]></dc:creator><pubDate>Fri, 31 Jan 2014 19:02:53 GMT</pubDate><content:encoded><![CDATA[<p>Google web performance engineer <a href="http://www.igvita.com/">Ilya Grigorik</a> has put together the definitive tome on bleeding-edge, high speed web apps. The book is packed with information on performance optimization best practices for TCP, UDP, and TLS protocols, and explains unique wireless and mobile network optimization requirements:  </p>

<blockquote>How prepared are you to build fast and efficient web applications? This eloquent book provides what every web developer should know about the network, from fundamental limitations that affect performance to major innovations for building even more powerful browser applications—including HTTP 2.0 and XHR improvements, Server-Sent Events (SSE), WebSocket, and WebRTC.</blockquote>  

<p>It's free <a href="http://chimera.labs.oreilly.com/books/1230000000545/index.html">in HTML format</a> via <a href="http://velocityconf.com/">Velocity Conference</a>.</p>]]></content:encoded></item><item><title><![CDATA[Signs that you're a good programmer]]></title><description><![CDATA[<p>A truly superb <a href="https://sites.google.com/site/yacoset/Home/signs-that-you-re-a-good-programmer" title="Signs that you’re a good programmer">list of aspirational qualities</a> for software developers. It includes symptoms of each particular quality and guidelines on how to acquire the desired traits.</p>

<blockquote>Signs that you're a good programmer

1. The instinct to experiment first  
2. Emotional detachment from code and design  
3. Eager to fix what</blockquote>]]></description><link>https://www.binarysludge.com/2013/05/01/signs-that-youre-a-good-programmer/</link><guid isPermaLink="false">91687bba-0ad8-4a43-b591-7a17132df319</guid><category><![CDATA[Debugging]]></category><category><![CDATA[Programming]]></category><category><![CDATA[source code]]></category><dc:creator><![CDATA[Andrew Martin]]></dc:creator><pubDate>Wed, 01 May 2013 20:20:06 GMT</pubDate><content:encoded><![CDATA[<p>A truly superb <a href="https://sites.google.com/site/yacoset/Home/signs-that-you-re-a-good-programmer" title="Signs that you’re a good programmer">list of aspirational qualities</a> for software developers. It includes symptoms of each particular quality and guidelines on how to acquire the desired traits.</p>

<blockquote>Signs that you're a good programmer

1. The instinct to experiment first  
2. Emotional detachment from code and design  
3. Eager to fix what isn't broken  
4. Fascinated by the incomprehensible  
5. Compelled to teach

Signs that you're a fantastic programmer

1. Incorruptible patience  
2. A destructive pursuit of perfection  
3. Encyclopedic grasp of the platform  
4. Thinks In Code  
5. When In Rome, Does As Romans Do  
6. Creates their own tools

Signs that you're destined for more

1. Indifferent to Hierarchy  
2. Excited by failure  
3. Indifferent to circumstances  
4. Unswayed by obligations  
5. Substitutes impulse for commitment  
6. Driven by experiences  
</blockquote>]]></content:encoded></item><item><title><![CDATA[Know Your Onions (and Antipatterns)]]></title><description><![CDATA[<p>Antipatterns (styles of design or process that may proliferate, but are ineffectual or counter-productive) can confound even the most battle-hardened of developers. Only knowledge can set us free, and to that end Source Making's list of antipatterns is a welcome reminder. </p><blockquote><p>Good software structure is essential for system extension and</p></blockquote>]]></description><link>https://www.binarysludge.com/2013/04/14/know-your-onions-and-antipatterns/</link><guid isPermaLink="false">bafeef2e-1682-4aa7-8804-36f59f66a14a</guid><category><![CDATA[Clean Code]]></category><category><![CDATA[Code review]]></category><category><![CDATA[Programming]]></category><category><![CDATA[software engineering]]></category><category><![CDATA[source code]]></category><category><![CDATA[TDD]]></category><category><![CDATA[Antipatterns]]></category><dc:creator><![CDATA[Andrew Martin]]></dc:creator><pubDate>Sun, 14 Apr 2013 23:07:20 GMT</pubDate><content:encoded><![CDATA[<p>Antipatterns (styles of design or process that may proliferate, but are ineffectual or counter-productive) can confound even the most battle-hardened of developers. Only knowledge can set us free, and to that end Source Making's list of antipatterns is a welcome reminder. </p><blockquote><p>Good software structure is essential for system extension and maintenance. Software development is a chaotic activity, therefore the implemented structure of systems tends to stray from the planned structure as determined by architecture, analysis, and&nbsp;design.</p></blockquote><p><a href="http://sourcemaking.com/antipatterns/software-development-antipatterns">Software Development AntiPatterns</a></p>]]></content:encoded></item><item><title><![CDATA[The analogy of print and code reviews]]></title><description><![CDATA[<p>Eerie similarities:</p><blockquote><p>First, from your editor, as from your butler, there are no secrets. If you have allowed yourself to be lazy, careless, turgid, or sloppy, there is no concealing it.

Second, everyone &ndash; everyone &ndash; is capable of shoddy work, especially in the first draft. That is why writers</p></blockquote>]]></description><link>https://www.binarysludge.com/2013/03/27/the-analogy-of-print-and-code-reviews/</link><guid isPermaLink="false">bb47a7d4-6c0c-4170-aa2f-723b4d6fa39b</guid><category><![CDATA[Code review]]></category><category><![CDATA[Programming]]></category><category><![CDATA[source code]]></category><dc:creator><![CDATA[Andrew Martin]]></dc:creator><pubDate>Wed, 27 Mar 2013 12:59:00 GMT</pubDate><content:encoded><![CDATA[<p>Eerie similarities:</p><blockquote><p>First, from your editor, as from your butler, there are no secrets. If you have allowed yourself to be lazy, careless, turgid, or sloppy, there is no concealing it.

Second, everyone &ndash; everyone &ndash; is capable of shoddy work, especially in the first draft. That is why writers need editing, not just self-editing, but editing from an independent set of eyes.

Third, humility should be the outcome. The writer should understand the human propensity toward error, and the editor should not assume some snooty sense of superiority for having ferreted out errors, because the editor is equally prone to them.*</p></blockquote><p>* Anyone who doubts the fallibility of editors should see these confessions at the&nbsp;<a title="The Subversive Copy Editor Blog: Copyeditor confessions: Me first" href="http://www.subversivecopyeditor.com/blog/2013/03/copyeditor-confessions-me-first.html">Subversive Copy Editor Blog</a>.

<a href="http://stancarey.wordpress.com/2013/03/26/book-review-the-old-editor-says-by-john-mcintyre/">Book review: The Old Editor Says, by John McIntyre | Sentence first</a></p>]]></content:encoded></item><item><title><![CDATA[Write It Like It’s Stolen: Keeping Software Security After Theft]]></title><description><![CDATA[<p align="center">  
<img class="alignleft mainimage" style="margin-left: 0pt; margin-top: 13pt;" title="Symantec Logo" src="http://www.symantec.com/content/en/us/about/images/photos/low_res/logos/SYM_Vert_RGB-72dpi.jpg" alt="Symantec Logo" width="100"></p>

<p><a href="http://deadliestwebattacks.com/2012/02/26/write-it-like-its-stolen/">Deadliest Web Attacks</a> has published an article rallying against the dearth of high quality, secure code. Although most code is never seen by anyone but the core development team, in light of the recent <a href="http://www.channelregister.co.uk/2012/01/18/symantec_leak_latest/">Symantec source code theft</a> the article is particularly pertinent:</p>

<blockquote>How would you alter the risks associated</blockquote>]]></description><link>https://www.binarysludge.com/2012/02/29/write-it-like-its-stolen-keeping-software-security-after-theft/</link><guid isPermaLink="false">dbe37348-76fc-4d7c-818a-199574c80d00</guid><category><![CDATA[OWASP]]></category><category><![CDATA[security]]></category><category><![CDATA[source code]]></category><dc:creator><![CDATA[Andrew Martin]]></dc:creator><pubDate>Wed, 29 Feb 2012 06:53:44 GMT</pubDate><content:encoded><![CDATA[<p align="center">  
<img class="alignleft mainimage" style="margin-left: 0pt; margin-top: 13pt;" title="Symantec Logo" src="http://www.symantec.com/content/en/us/about/images/photos/low_res/logos/SYM_Vert_RGB-72dpi.jpg" alt="Symantec Logo" width="100"></p>

<p><a href="http://deadliestwebattacks.com/2012/02/26/write-it-like-its-stolen/">Deadliest Web Attacks</a> has published an article rallying against the dearth of high quality, secure code. Although most code is never seen by anyone but the core development team, in light of the recent <a href="http://www.channelregister.co.uk/2012/01/18/symantec_leak_latest/">Symantec source code theft</a> the article is particularly pertinent:</p>

<blockquote>How would you alter the risks associated with your web site if its source code were stolen? Hard-coded passphrases? String concatenation of SQL statements? How much security relies on secrecy of functionality versus secrecy of data? Think of it in terms of Kerchoff’s Principle, roughly “The system must not require secrecy and can be stolen by the enemy without causing trouble”. Kerchoff was writing about cryptography, but the concept applies well to software.</blockquote>

<p>This would be a good time to double-check the <a href="https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project">OWASP Top Ten Vulnerabilities</a> and re-watch the <a href="https://www.owasp.org/index.php/OWASP_Appsec_Tutorial_Series">OWASP Appsec Tutorial Series</a>.<br></p>]]></content:encoded></item></channel></rss>