Domain > blog.oofn.net

Welcome! Right click nodes and scroll the mouse to navigate the graph.

More information on this domain is in AlienVault OTX

DNS Resolutions

Date	IP Address
2019-09-20	66.33.215.212 (ClassC)
2025-01-18	173.236.195.204 (ClassC)

HTTP/1.1 200 OKDate: Sat, 18 Jan 2025 21:30:56 GMTServer: ApacheLink: https://blog.oofn.net/wp-json/>; relhttps://api.w.org/Upgrade: h2Connection: UpgradeCache-Control: max-age600Expires: Sat, 18 Jan 2025 21:40:56 GMTVary: Accept-Encoding,User-AgentContent-Length: 28376Content-Type: text/html; charsetUTF-8

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd>html xmlnshttp://www.w3.org/1999/xhtml>head profilehttp://gmpg.org/xfn/11>		title>Chad Weider/title>	meta propertytwitter:account_id content10478352 />	meta http-equivContent-Type contentapplication/xhtml+xml; charsetUTF-8 />		script typetext/javascript>		var gaJsHost  ((https:  document.location.protocol) ? https://ssl. : http://www.);		document.write(unescape(%3Cscript src + gaJsHost + google-analytics.com/ga.js typetext/javascript%3E%3C/script%3E));	/script>	script typetext/javascript>		var pageTracker  _gat._getTracker(UA-814151-1);		pageTracker._initData();		pageTracker._trackPageview();	/script>		link relstylesheet typetext/css hrefhttps://blog.oofn.net/wp-content/themes/default/style.css />	link relalternate typeapplication/rss+xml titleRSS 2.0 hrefhttps://blog.oofn.net/feed/ />		link relstylesheet typetext/css hrefhttps://blog.oofn.net/wp-content/themes/default/blog.css/>/head>body>		div idheader>		h1 idtitle>a hrefhttps://blog.oofn.net>Chad Weider/a>/h1>		span idcaption>You have found the home of/span>		ul idnavbar>		li>a idnavlink-blog hrefhttps://blog.oofn.net>Blog/a>/li>		li>a idnavlink-about hrefhttps://blog.oofn.net/about>About/a>/li>		li>a idnavlink-projects hrefhttps://blog.oofn.net/projects>Projects/a>/li>		/ul>	/div>	div idmain> !--div main starts-->		div idcontent> !--div content starts-->									div classpost> !--div post starts-->				div classpost-head>					h2 classpost-title>a hrefhttps://blog.oofn.net/2012/05/06/a-folk-history-of-hayes-valley/ relbookmark>A Folk History of Hayes Valley/a>/h2>					span classpost-meta>May 6, 2012 @ 9:08 pm/span>				/div>								div classpost-content>				p>Folk, common, local, whatever, history is a fascinating thing (no surprise then, that I grew up listening to *This American Life*(http://www.thisamericanlife.org/)). I’m convinced(http://en.wikipedia.org/wiki/Interesting_number_paradox) that there is no place you can find that is not interesting, especially if you happen to live in a large city./p>p>I live in the Hayes Valley neighborhood of San Francisco. While it does seem neat, clean, and nice, if you pull things back and look beyond the gentrification, the boutiques, the parks, the disappeared freeway, and the earthquake(http://en.wikipedia.org/wiki/Loma_Prieta_earthquake) – back into the ’80s – you would find the identity and experience of this neighborhood completely different. Back then the neighborhood (but, honestly, most parts of most cities) was pretty “edgy” Indeed, in 1979, Chris Pirsig (from *ZAMM*(http://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance)) was murdered(http://www.sfgate.com/cgi-bin/article.cgi?f/c/a/2004/11/19/WBGKJ9SCPS1.DTL) a few blocks away from my apartment./p>p>However, despite all of the drama of the moment, in history, most events are forgotten and stories remain untold. I’d reserve judgment on whether or not this is a good thing, but, good or bad, this does make the discovery of those stories, regardless of provenance, something precious./p>p>Anyways, not to make to too much of it, a while ago I dug up a short history about growing up in this neighborhood – way before I ever stepped foot in it – and I think it’s pretty interesting:/p>p>*Chronicles Of A True Hustler*:br />Pt. 1(http://dailymath.ihiphop.com/weblog/?p78),br />Pt. 2(http://dailymath.ihiphop.com/weblog/?p84),br />Pt. 3(http://dailymath.ihiphop.com/weblog/?p90),br />Pt. 4(http://dailymath.ihiphop.com/weblog/?p100),br />Pt. 5(http://dailymath.ihiphop.com/weblog/?p111),br />Pt. 6(http://dailymath.ihiphop.com/weblog/?p120), *Archived*(http://dailymathematics.blogspot.com/search?qchronicles+hustler&by-datetrue)/p>				/div>								!--				div classpost-feedback>								a hrefhttps://blog.oofn.net/2012/05/06/a-folk-history-of-hayes-valley/#respond>Comments (0)/a>				/div>				rdf:RDF xmlns:rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#			xmlns:dchttp://purl.org/dc/elements/1.1/			xmlns:trackbackhttp://madskills.com/public/xml/rss/module/trackback/>		rdf:Description rdf:abouthttps://blog.oofn.net/2012/05/06/a-folk-history-of-hayes-valley/    dc:identifierhttps://blog.oofn.net/2012/05/06/a-folk-history-of-hayes-valley/    dc:titleA Folk History of Hayes Valley    trackback:pinghttps://blog.oofn.net/2012/05/06/a-folk-history-of-hayes-valley/trackback/ />/rdf:RDF>								-->			/div> !--div post ends-->									div classpost> !--div post starts-->				div classpost-head>					h2 classpost-title>a hrefhttps://blog.oofn.net/2012/04/22/emulating-uibarbuttonitem-appearance/ relbookmark>Emulating UIBarButtonItem Appearance/a>/h2>					span classpost-meta>April 22, 2012 @ 12:18 pm/span>				/div>								div classpost-content>				p>While it’s best to avoid, sometimes it you must duplicate the appearance of code>UIToolbar/code> items. Unfortunately, UIKit doesn’t appear to provide any means for achieving the etched look that it adds on each item it has control over so, for custom code>UIBarButtonItem/code>s you must do it manually./p>p>img decodingasync classcenter src/pictures/mines_status_bar.png>/p>p>In my case, I needed to present some information on the toolbar, but needed it to be non-interactive, have a special layout, and use some existing vector images. To that end, here are some category methods that made it straight forward: https://gist.github.com/2465637(https://gist.github.com/2465637)./p>p>Given that, etching can be had with a few lines. It’s not efficient, but it is easy./p>pre>UIImage ct_imageWithPDFNamed:@time size:CGSizeMake(26, 26)  ct_imageWithOverlayColor:UIColor colorWithRed:112/255. green:119/255. blue:123/255. alpha:1  ct_imageWithInnerShadowOffset:CGSizeMake(0, 1) color:UIColor colorWithWhite:0 alpha:.6  ct_imageWithShadowOffset:CGSizeMake(0, 1) blur:0 color:UIColor colorWithWhite:1 alpha:.6/pre>				/div>								!--				div classpost-feedback>								a hrefhttps://blog.oofn.net/2012/04/22/emulating-uibarbuttonitem-appearance/#respond>Comments (0)/a>				/div>				rdf:RDF xmlns:rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#			xmlns:dchttp://purl.org/dc/elements/1.1/			xmlns:trackbackhttp://madskills.com/public/xml/rss/module/trackback/>		rdf:Description rdf:abouthttps://blog.oofn.net/2012/04/22/emulating-uibarbuttonitem-appearance/    dc:identifierhttps://blog.oofn.net/2012/04/22/emulating-uibarbuttonitem-appearance/    dc:titleEmulating UIBarButtonItem Appearance    trackback:pinghttps://blog.oofn.net/2012/04/22/emulating-uibarbuttonitem-appearance/trackback/ />/rdf:RDF>								-->			/div> !--div post ends-->									div classpost> !--div post starts-->				div classpost-head>					h2 classpost-title>a hrefhttps://blog.oofn.net/2012/04/21/i-shipped-a-thing/ relbookmark>I Shipped a Thing/a>/h2>					span classpost-meta>April 21, 2012 @ 8:25 pm/span>				/div>								div classpost-content>				p>Late last week a a hrefhttp://halfworking.com/mines>little app/a> of mine made its way onto the a hrefhttp://itunes.com/apps/halfworking/mines>App Store/a>. So congratulations to me! but, uh, a minesweeper clone? that would *not* be very original. Nope, it’s not very original, but it is *better*./p>p>img decodingasync classcenter src/pictures/mines_screenshot.png width240px height360px>/p>p>It is my weak protest against the garish(http://itunes.apple.com/us/app/minesweeper-*****/id407768156?mt8) implementations that litter the App Store. It’s not something I’d plan to profit from (game development has always seemed to be an inevitably feral existence), but an argument for quality in the App Store, where barring a few(http://carcassonneapp.com/) exceptions(http://cocoastuff.com/products/deepgreen) it can seem like there is so little./p>p>…It was also fun to do./p>p>…How many times have I heard *that* said before?/p>				/div>								!--				div classpost-feedback>								a hrefhttps://blog.oofn.net/2012/04/21/i-shipped-a-thing/#respond>Comments (0)/a>				/div>				rdf:RDF xmlns:rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#			xmlns:dchttp://purl.org/dc/elements/1.1/			xmlns:trackbackhttp://madskills.com/public/xml/rss/module/trackback/>		rdf:Description rdf:abouthttps://blog.oofn.net/2012/04/21/i-shipped-a-thing/    dc:identifierhttps://blog.oofn.net/2012/04/21/i-shipped-a-thing/    dc:titleI Shipped a Thing    trackback:pinghttps://blog.oofn.net/2012/04/21/i-shipped-a-thing/trackback/ />/rdf:RDF>								-->			/div> !--div post ends-->									div classpost> !--div post starts-->				div classpost-head>					h2 classpost-title>a hrefhttps://blog.oofn.net/2012/04/16/quick-and-dirty-high-dpi-images/ relbookmark>Quick and Dirty High-DPI Images/a>/h2>					span classpost-meta>April 16, 2012 @ 2:59 pm/span>				/div>								div classpost-content>				p>While working on this page(http://halfworking.com/mines), I discovered just how awful the web can look on the the the iPhone and iPad with their â€œretinaâ€ screens. In native applications, normal resolution images are scaled without anti-aliasing, but in Mobile Safari images are scaled _with_ anti-aliasing, and as a consequence, many important pixels can get badly blurred./p>p>This isnâ€™t an unrecognized problem and it has been solved elsewhere(http://flowz.com/2010/07/css-image-replacement-for-iphone-4-high-dpi-retina-display/), but the accepted approach seems require JavaScript and class names, which strikes me as unnecessary â€“ CSS declarations alone should suffice./p>p>To that end, the approach I use is this(https://gist.github.com/2394800):/p>pre>@media only screen and -webkit-min-device-pixel-ratio:2 {  imgsrcimages/icon.png {    content: url(images/icon@2x.png);  }  imgsrcimages/store_small.png {    content: url(images/store_small@2x.png);  }  imgsrcimages/screen_fail.png {    content: url(images/screen_fail@2x.png);  }  imgsrcimages/screen_play.png {    content: url(images/screen_play@2x.png);  }}/pre>p>*I swear I read about content negotiation for this at some point, but all I can find is an old, unresolved discussion(https://lists.webkit.org/pipermail/webkit-dev/2007-June/001923.html) at webkit.org(http://webkit.org)./p>				/div>								!--				div classpost-feedback>								a hrefhttps://blog.oofn.net/2012/04/16/quick-and-dirty-high-dpi-images/#respond>Comments (0)/a>				/div>				rdf:RDF xmlns:rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#			xmlns:dchttp://purl.org/dc/elements/1.1/			xmlns:trackbackhttp://madskills.com/public/xml/rss/module/trackback/>		rdf:Description rdf:abouthttps://blog.oofn.net/2012/04/16/quick-and-dirty-high-dpi-images/    dc:identifierhttps://blog.oofn.net/2012/04/16/quick-and-dirty-high-dpi-images/    dc:titleQuick and Dirty High-DPI Images    trackback:pinghttps://blog.oofn.net/2012/04/16/quick-and-dirty-high-dpi-images/trackback/ />/rdf:RDF>								-->			/div> !--div post ends-->									div classpost> !--div post starts-->				div classpost-head>					h2 classpost-title>a hrefhttps://blog.oofn.net/2011/04/21/yajsml/ relbookmark>YAJSML/a>/h2>					span classpost-meta>April 21, 2011 @ 2:35 am/span>				/div>								div classpost-content>				p>Ugh, I’m pretty tired of the endless parade of “Oh hai, iz wrtn a JS loaderz” projects. Given the number of existing implementations and the general solved-ness of the problem, the time devoted to it is disappointing. But here I am, doing just the same./p>p>## Principles/p>p>This work is related to that done in RequireJS(http://requirejs.org/) and CommonJS(http://wiki.commonjs.org/wiki/Modules), but hardly bound(http://tagneto.blogspot.com/) by them. Instead, the results are a product of the following principles:/p>p>* Improving the loading characteristics of a JavaScript project should be approached as an incremental optimization problem.br />* Simplicity is best. Only implement the necessary features.br />* Caching should be exploited. Expensive one-time operations are acceptable provided their responses are reusable.br />* Modules(http://wiki.commonjs.org/wiki/Modules/1.1.1) are well defined, widely used, and well founded. The five different asynchronous loading specifications, not so much./p>p>This leads to what I’m given to think is a much simpler version that works(http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html) than existing implementations. The other nice thing is that the packaging tool takes an original approach to solving the dependency issue./p>p>## Observations/p>p>### Optimizationbr />Naïve implementations are good. Those implementations may be slow, but they are also cheap and set the stage for proper optimization(http://c2.com/cgi/wiki?RulesOfOptimization). Chances are, that many possible optimizations are rendered unnecessary by the right tools./p>p>### Dependenciesbr />Most current implementations use one of five(http://wiki.commonjs.org/wiki/Modules/Transport) ways to wrap a module’s code with a description of the dependencies that that code requires, and which a library will fetch asynchronously, finally evaluating the modules code once all are loaded. The thought being that, once that module is received, first all of its dependencies need loading (asynchronously so they are non-blocking, natch)./p>p>IMHO, that obscures the more obvious and important observation, that having dependencies that aren’t loaded by the time the current module is loaded, asynchronous or not, is *never* good. If this is to be treated as an optimization problem, then the issue is one of packaging. If the packaging works well, the question of synchronous/asynchronous loading is moot./p>p>### Packagingbr />Existing packagers all perform some sort of parsing on source files, usually a regular expression, maybe a full preprocessor language. Both approaches have the downsides of requiring boilerplate code or being unreliable. There is also the additional complication of describing lazy dependencies so that they do not get confused with loading dependencies./p>p>The good news is that, given the availability of non-browser interpreters, there is a third way, where the code itself can be evaluated offline and dependencies *extracted during run-time*. Not only would this extract only those dependencies needed exactly at load time and require no boilerplate, using the same kernel in both environments, it would keep both the client and the packager’s results consistent./p>p>### Versioningbr />The current practice for deploying JavaScript is to set a query parameter like `bustv_n+1` on the URL of the script’s location to, in effect, invalidate the cache. This happens to work in the monolithic file case, however, lazy loading code makes versioning a problem that cannot be ignored. While new clients will use `v_n+1`, clients using `v_n` code must continue to receive `v_n` code. For this reason, versioning should be reflected in the base URI./p>p>code>br />http://assets1.example.com/js/src/n/br />http://assets1.example.com/js/src/n+1/br />http://assets1.example.com/js/src/n+2/br />/code>/p>p>### Cachingbr />It’s a common observation that different areas of a project change at different rates. This is certainly the case in web applications where library code will change much slower than application code. It follows then that updates to application code should have no effect on still cacheable library code./p>p>Convention already specifies this using a leading slash for `’/application/code’` and none for `’library/code’`. This is simple to exploit by allowing different URIs for the two classes of code./p>p>code>br />http://assets1.example.com/js/lib/0.1.2/br />http://assets1.example.com/js/src/0.3.0/br />/code>/p>p>## Implementationbr />The tool that implements this loader provides two things things, a kernel and a module compiler. For the moment it is on an experimental branch(https://github.com/cweider/modulizer/tree/experimental) of the Modulizer project, though I’m beginning to like “Yajsml” more and more./p>p>The kernel is a terse bit of JS that provides the module loading and fetching functionality. It has no references to the global environment and, by default, exports to the `require` symbol. It’s the part that enables a simple page like this:/p>pre styleoverflow-x:scroll><script typetext/javascript src/kernel.js></script><script typetext/javascript>  require.setRootURI(/js/src/);  require.setLibraryURI(/js/lib/);  require.setGlobalKeyPath(require);  app  new (require(/app).Application)({    userId: 1234  , baseURI: http://example.com/  });</script>/pre>p>The module compiler takes a number of paths and compiles them into a `require.define()` call. Using the command line tool:/p>pre>../modulize --output code.js.     \            --root-path ./src     \            --library-path ./lib  \             --import-dependencies -- ./src/app.js/pre>p>Produces the following package:/p>pre styleoverflow-x:scroll>require.define({  /app: null, /app.js: function (require, exports, module) {    var models  require(/models);    var util  require(util);  }, /models: null, /models.js: null, /models/group: null, /models/group.js: function (require, exports, module) {    exports.Group  function () {      /*...*/    };  }, /models/index: null, /models/index.js: function (require, exports, module) {    exports.User  require(./user).User;    exports.Group  require(./group).Group;  }, /models/user: null, /models/user.js: function (require, exports, module) {    exports.User  function () {      /*...*/    };  }, util: null, util.js: null, util/index: null, util/index.js: function (require, exports, module) {    exports.escapeHTML  function () {};    exports.escapeHTMLAttribute  function () {};    exports.importantURL  http://example.com/;  }});/pre>p>## Futurebr />This the first iteration in a longer project with several more big ideas to adopt, but, IMHO, aside from one or two missing features, this is a pretty comprehensive solution for the problem of distributing code from the client’s perspective. The remaining improvements revolve around improving the optimization of packaging and using the cache more effectively./p>p>Regarding effective use of the cache, having module requests get redirected to designated/canonical packages has lots of potential to increase cache hits when loading order varies – such as across pages. As far as finding an optimal packaging goes, it’s the kind of problem that sounds like the perfect job for some sort of nondeterministic heuristic-ish algorithm./p>p>And finally, while the two buckets, `libraryURI` and `rootURI`, are probably sufficient for most projects, the thought of allowing for multiple library paths is appealing. Searching would of course be made more expensive for some modules, but I suspect that ordering the search paths by increasing frequency of updates may allow caching to compensate for this./p>p>## Updatesbr />It’s since become clear that parts of this discussion are reasonably independent of each other, so they’ve been broken into their own projects:/p>p>– require-kernel(https://github.com/cweider/require-kernel): A minimalist implementation of `require` that supports asynchronous retrieval.br />– yajsml(https://github.com/cweider/yajsml): An asset server that  performs packaging and clever things like redirecting to a canonical resource.br />– modulizer(https://github.com/cweider/yajsml): A tool that finds  dependencies at runtime./p>				/div>								!--				div classpost-feedback>								a hrefhttps://blog.oofn.net/2011/04/21/yajsml/#respond>Comments (0)/a>				/div>				rdf:RDF xmlns:rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#			xmlns:dchttp://purl.org/dc/elements/1.1/			xmlns:trackbackhttp://madskills.com/public/xml/rss/module/trackback/>		rdf:Description rdf:abouthttps://blog.oofn.net/2011/04/21/yajsml/    dc:identifierhttps://blog.oofn.net/2011/04/21/yajsml/    dc:titleYAJSML    trackback:pinghttps://blog.oofn.net/2011/04/21/yajsml/trackback/ />/rdf:RDF>								-->			/div> !--div post ends-->									div classpost> !--div post starts-->				div classpost-head>					h2 classpost-title>a hrefhttps://blog.oofn.net/2011/04/10/finding-javascripts-global-object/ relbookmark>Finding JavaScript’s Global Object/a>/h2>					span classpost-meta>April 10, 2011 @ 5:06 pm/span>				/div>								div classpost-content>				p>With JavaScript code being written in ever more diverse environments these days, some assumptions are bound to get broken. One such assumption is that the object bound to the symbol code>window/code> in the current scope is the global object. Every approach I’ve seen searches through a list of probable symbols and returns the first defined, instead of using the language itself./p>p>code>var global  (typeof window ! undefined ? window : global)/code>/p>p>Below is a snippet that will return the global object independent of scope and interpreter./p>p>code>var global  (function () {return this})();/code>/p>p>em>Note: except in the rarest of cases, direct address of the global object is illegitimate regardless of approach, using this more robust snippet is no excuse.em>/em>/em>/p>				/div>								!--				div classpost-feedback>								a hrefhttps://blog.oofn.net/2011/04/10/finding-javascripts-global-object/#respond>Comments (0)/a>				/div>				rdf:RDF xmlns:rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#			xmlns:dchttp://purl.org/dc/elements/1.1/			xmlns:trackbackhttp://madskills.com/public/xml/rss/module/trackback/>		rdf:Description rdf:abouthttps://blog.oofn.net/2011/04/10/finding-javascripts-global-object/    dc:identifierhttps://blog.oofn.net/2011/04/10/finding-javascripts-global-object/    dc:titleFinding JavaScript’s Global Object    trackback:pinghttps://blog.oofn.net/2011/04/10/finding-javascripts-global-object/trackback/ />/rdf:RDF>								-->			/div> !--div post ends-->						div styleposition:relative; margin-left:50px; height:20px;>				div styleposition:absolute; left:0px;>/div>				div styleposition:absolute; right:0px;>a hrefhttps://blog.oofn.net/page/2/ >Older Entries »/a>/div>			/div>		/div> !--div content ends-->				div idsidebar>			ul>			li classsidebar-listgroup sidebar-categories idcategories>Categories:				ul>					li classcat-item cat-item-4>a hrefhttps://blog.oofn.net/category/cool/>Cool/a>/li>	li classcat-item cat-item-10>a hrefhttps://blog.oofn.net/category/design/>Design/a>/li>	li classcat-item cat-item-5>a hrefhttps://blog.oofn.net/category/development/>Development/a>ul classchildren>	li classcat-item cat-item-13>a hrefhttps://blog.oofn.net/category/development/javascript/>JavaScript/a>/li>/ul>/li>	li classcat-item cat-item-8>a hrefhttps://blog.oofn.net/category/life/>Life/a>/li>	li classcat-item cat-item-6>a hrefhttps://blog.oofn.net/category/mac/>Mac/a>/li>	li classcat-item cat-item-2>a hrefhttps://blog.oofn.net/category/observations/>Observations/a>/li>	li classcat-item cat-item-3>a hrefhttps://blog.oofn.net/category/rants/>Rants/a>/li>	li classcat-item cat-item-7>a hrefhttps://blog.oofn.net/category/university/>University/a>/li>	li classcat-item cat-item-12>a hrefhttps://blog.oofn.net/category/users/>Users/a>/li>				/ul>			/li>			li classsidebar-listgroup sidebar-archives idarchives>Archives:				ul>					li>a hrefhttps://blog.oofn.net/2012/05/>May 2012/a>/li>	li>a hrefhttps://blog.oofn.net/2012/04/>April 2012/a>/li>	li>a hrefhttps://blog.oofn.net/2011/04/>April 2011/a>/li>	li>a hrefhttps://blog.oofn.net/2008/06/>June 2008/a>/li>	li>a hrefhttps://blog.oofn.net/2008/05/>May 2008/a>/li>	li>a hrefhttps://blog.oofn.net/2008/04/>April 2008/a>/li>	li>a hrefhttps://blog.oofn.net/2008/03/>March 2008/a>/li>	li>a hrefhttps://blog.oofn.net/2008/02/>February 2008/a>/li>	li>a hrefhttps://blog.oofn.net/2007/10/>October 2007/a>/li>	li>a hrefhttps://blog.oofn.net/2007/08/>August 2007/a>/li>	li>a hrefhttps://blog.oofn.net/2007/07/>July 2007/a>/li>	li>a hrefhttps://blog.oofn.net/2007/06/>June 2007/a>/li>	li>a hrefhttps://blog.oofn.net/2007/05/>May 2007/a>/li>	li>a hrefhttps://blog.oofn.net/2007/03/>March 2007/a>/li>	li>a hrefhttps://blog.oofn.net/2007/02/>February 2007/a>/li>	li>a hrefhttps://blog.oofn.net/2006/11/>November 2006/a>/li>	li>a hrefhttps://blog.oofn.net/2006/09/>September 2006/a>/li>	li>a hrefhttps://blog.oofn.net/2006/08/>August 2006/a>/li>	li>a hrefhttps://blog.oofn.net/2006/07/>July 2006/a>/li>	li>a hrefhttps://blog.oofn.net/2006/05/>May 2006/a>/li>	li>a hrefhttps://blog.oofn.net/2006/04/>April 2006/a>/li>	li>a hrefhttps://blog.oofn.net/2006/03/>March 2006/a>/li>	li>a hrefhttps://blog.oofn.net/2006/02/>February 2006/a>/li>	li>a hrefhttps://blog.oofn.net/2006/01/>January 2006/a>/li>	li>a hrefhttps://blog.oofn.net/2005/11/>November 2005/a>/li>	li>a hrefhttps://blog.oofn.net/2005/10/>October 2005/a>/li>				/ul>			/li>			li classsidebar-listgroup sidebar-Links idLinks>Links:				ul>				li>a hrefhttp://thetalik.net titleHey, it’s my brother!>Derek Weider/a>/li>li>a hrefhttp://www.joeyhagedorn.com/ titleHacker @ UIUC>Joey Hagedorn/a>/li>li>a hrefhttp://www.theronge.com>Matt Ronge/a>/li>li>a hrefhttp://del.icio.us/cweider>My del.icio.us/a>/li>li>a hrefhttp://twitter.com/cweider>My twitter/a>/li>li>a hrefhttp://blog.klockenga.net>Nick Klockenga/a>/li>li>a hrefhttp://www.rentzsch.com/ titleJonathan Wolfgang Von Rentzsch – Mac Ãœberdeveloper>Rentzsch/a>/li>				/ul>			/li>			/ul>		/div>	/div> !--div main ends-->		div idfooter> !--div footer starts-->		span idcredit>Copyright © Chad Weider 2005–2008/span>	/div> !--div footer ends-->/body>/html>

View on OTX | View on ThreatMiner

Data with thanks to AlienVault OTX, VirusTotal, Malwr and others. [Sitemap]

Domain > blog.oofn.net

Is this malicious?

DNS Resolutions

Port 80

Port 443