<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Github on Brave New Geek</title><link>https://bravenewgeek.com/tag/github/</link><description>Recent content in Github on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 15 Oct 2020 10:51:25 -0500</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/github/index.xml" rel="self" type="application/rss+xml"/><item><title>Continuous Deployment for AWS Glue</title><link>https://bravenewgeek.com/continuous-deployment-for-aws-glue/</link><pubDate>Thu, 15 Oct 2020 10:51:25 -0500</pubDate><guid>https://bravenewgeek.com/continuous-deployment-for-aws-glue/</guid><description>&lt;p&gt;&lt;a href="https://aws.amazon.com/glue"&gt;AWS Glue&lt;/a&gt; is a managed service for building ETL (Extract-Transform-Load) jobs. It’s a useful tool for implementing analytics pipelines in AWS without having to manage server infrastructure. Jobs are implemented using Apache Spark and, with the help of &lt;a href="https://docs.aws.amazon.com/glue/latest/dg/dev-endpoints.html"&gt;Development Endpoints&lt;/a&gt;, can be built using Jupyter notebooks. This makes it reasonably easy to write ETL processes in an interactive, iterative fashion. Once finished, the Jupyter notebook is converted into a Python script, uploaded to S3, and then run as a Glue job.&lt;/p&gt;</description></item><item><title>Security by Happenstance</title><link>https://bravenewgeek.com/security-by-happenstance/</link><pubDate>Tue, 26 Mar 2019 11:25:14 -0500</pubDate><guid>https://bravenewgeek.com/security-by-happenstance/</guid><description>&lt;h4 id="key-rotation-auditing-and-securecicd"&gt;Key rotation, auditing, and secure CI/CD&lt;/h4&gt;
&lt;p&gt;Companies often require employees to regularly change their passwords for security purposes. &lt;a href="https://www.pcisecuritystandards.org/document_library?category=pcidss&amp;amp;document=pci_dss"&gt;PCI compliance&lt;/a&gt;, for example, requires that passwords be changed every 90 days. However, NIST, whose guidelines commonly become the foundation for security best practices across countless organizations, &lt;a href="https://www.passwordping.com/surprising-new-password-guidelines-nist/"&gt;recently revised&lt;/a&gt; its recommendations around password security. Its Digital Identity Guidelines (&lt;a href="https://pages.nist.gov/800-63-3/sp800-63b.html"&gt;NIST 800-63-3&lt;/a&gt;) now recommends &lt;em&gt;removing&lt;/em&gt; periodic password-change requirements due to a growing body of research suggesting that frequent password changes actually &lt;a href="https://arstechnica.com/information-technology/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/"&gt;makes security &lt;em&gt;worse&lt;/em&gt;&lt;/a&gt;. This is because these requirements encourage the use of passwords which are more susceptible to cracking (e.g. incrementing a number or altering a single character) or result in people writing their passwords down.&lt;/p&gt;</description></item><item><title>Introducing InfinitumFramework.com</title><link>https://bravenewgeek.com/introducing-infinitumframework-com/</link><pubDate>Fri, 04 Jan 2013 01:36:36 -0600</pubDate><guid>https://bravenewgeek.com/introducing-infinitumframework-com/</guid><description>&lt;p&gt;&lt;a href="http://www.infinitumframework.com/"&gt;&lt;img alt="rendering" loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2013/01/rendering.png"&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href="http://www.infinitumframework.com/"&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href="http://www.infinitumframework.com/"&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Here’s a dose of shameless self-promotion. It’s coming up on a year since I started development on Infinitum, and I’m targeting its first full release on its birthday, February 11. Shortly before I moved the project to GitHub, they deprecated the downloads service, so I needed to fine a home for distributing the binaries as well as the Javadoc.&lt;/p&gt;
&lt;p&gt;GitHub offers its pages service, but I figured I’d just host it myself. I threw together a website in a couple days and the result is &lt;a href="http://www.infinitumframework.com/"&gt;www.infinitumframework.com&lt;/a&gt;. This website will be used to host the latest (and previous) releases of the framework, its documentation, and, in the future, announcements and updates for it.&lt;/p&gt;</description></item><item><title>Modularizing Infinitum: A Postmortem</title><link>https://bravenewgeek.com/modularizing-infinitum-a-postmortem/</link><pubDate>Thu, 27 Dec 2012 16:04:16 -0600</pubDate><guid>https://bravenewgeek.com/modularizing-infinitum-a-postmortem/</guid><description>&lt;p&gt;In addition to getting the code migrated from &lt;a href="https://code.google.com/p/infinitum-framework/"&gt;Google Code&lt;/a&gt; to &lt;a href="https://github.com/infinitumframework"&gt;GitHub&lt;/a&gt;, one of my projects over the holidays was to modularize the Infinitum Android framework I’ve been working on for the past year.&lt;/p&gt;
&lt;p&gt;Infinitum began as a SQLite ORM and quickly grew to include a REST ORM implementation,  REST client, logging wrapper, DI framework, AOP module, and, of course, all of the framework tools needed to support these various functionalities. It evolved as I added more and more features in a semi-haphazard way. In my defense, the code was organized. It was logical. It made &lt;em&gt;sense&lt;/em&gt;. There was no method, but there also was no madness. Everything was in an appropriately named package. Everything was coded to an interface. There was no duplicated code. However, modularity — in terms of minimizing framework dependencies — wasn’t really in mind at the time, and the code was all in a single project.&lt;/p&gt;</description></item></channel></rss>