The JAMstack is a relativity new concept in web development, and it caught my attention because of the simplicity and speed at which pages load. The stack consists of Javascript, APIs, and Markup. Friends of mine had started coding in Go earlier in 2018, and I saw an opportunity to jump headfirst into the new stack with Go.
I began working on the Go web service that serves the blog posts about three weeks ago. I developed a simple service that provides a headless RESTful API to create, read, update, and delete blog posts. I also wrote a user authentication package that uses bcrypt for password hashing and JSON Web Tokens for API authentication. This was also my first experience writing API documentation using Swagger. The API is hosted on Digital Ocean and served using Cloudflare. Once the API was serving JSON, I had to tweak my front-end to request and receive the JSON coming from the API and parse it. The front-end uses basic HTML and CSS along with vue.js and vanilla JavaScript. This was my first time developing with vue.js, and because I needed something simple, I did not take advantage of all the features vue provides. The front-end is hosted for free with SSL on GitHub Pages.
Suppose you are looking for an open source project to contribute to; please consider contributing to this. The API and front-end source code are all open source, and you can see the roadmap for the API in the README on GitHub. You can view the API code and documentation. The HTML and JavaScript for my site is also available on GitHub.
With the rise of languages that provide package management tools, developers and software engineers are spending more time integrating than coding. There are many great open source projects around the internet, with many that are free to use. These projects vary greatly in terms of what they provide. Some provide advanced features such as machine learning frameworks, user authentication, data modeling, and time-series analysis. Others provide simple functionality such as padding text to the left or right on a webpage. Open source packages save developers hundreds of hours by providing functionality that the developer does not have to write herself. The developer can take the open source project and the code, modify it, if needed, and integrate the new functionality into her application. A convenient way to include open source projects in software projects is through package managers. The process for including an open source project, in most cases, is as easy as defining the project name and version in a text file. The developer can then run an install command to bring in the open source code. The code is now part of the developer’s software. Many developers then take advantage of the new features which they just installed and continue with the project.
The key statement is that the open source project code is now part of the developer’s codebase for her project.
Not only is the code part of the codebase, but the code will, in most cases, be pushed to production. This should raise a series of questions within the organization. What dependencies did the open source project bring in? Do those dependencies have known vulnerabilities? What other features or functions does the open source project provide? Do those features or functions increase the attack surface for hackers by providing additional attack vectors? Or worse, does the project contain backdoors or other avenues for malicious authors/contributors to gain access?
These are all risks associated with using open source projects. What data points could alleviate some of the risks to the organization when researching projects? Are projects with large communities more secure? Are projects with a certain number of downloads more secure? Does the number of collaborators make a difference? How about the number of commits? The number of pull requests? What metrics can be used to highlight and differentiate one project as potentially more secure than another? The total lines of code? I’ll attempt to answer these questions as I continue writing other parts of this series.
Understanding user behavior and interactions in mobile applications are critical for developers to understand where to spend limited resources when adding, updating, and testing features. Still, current tools do not do a good job of providing actionable insights. User behavior insights can provide value to the developer when it’s time to code and implement new features. Google Analytics and New Relic provide user insights, but they fall short when it comes to identifying user interactions and behaviors pertaining to mobile applications’ individual features. We have developed a framework with middleware that provides user interaction insights, using time-series analysis for hybrid mobile applications and an empirical study to showcase the value of the framework.
Full Paper: User Interaction Metrics for Hybrid Mobile Applications[1] ISBN: 1-60132-489-8, CSREA Press © Pages 30-35
I’m excited to be speaking at JFrog’s swampUP conference in May.
I’ll be speaking on using Xray and Artifactory to produce secure containers. Avoiding known security vulnerability in prod, providing the US Gov with a complete Bill or Materials and ensuring compliance with copyright laws does not need to be scary. A brief case study in how to use JFrog products to support missions and developers around the globe.
Sometimes I like to stash commands that I use regularly. Below is a snippet of code that I find helpful from time to time.
ansible {{comma separated host list}} -m shell -a 'shell command goes here' --become
Sometimes I like to stash commands that I use regularly. Below is a snippet of code that I find helpful from time to time. Here is a good script for catching sigterms inside of a docker container.
#!/bin/bash
term_handler() {
${TOMCAT_DIR}/bin/shutdown.sh
exit 143; # 128 + 15 -- SIGTERM
}
# setup handlers
# on callback, kill the last background process, which is tail -f /dev/null and execute the specified handler
trap 'kill ${!}; term_handler' SIGTERM
# run application
${TOMCAT_DIR}/bin/startup.sh
ln -sf /dev/stdout ${TOMCAT_DIR}/catalina.out
# wait forever
while true
do
tail -f /dev/null & wait ${!}
done
Abstract - The Internet is weak, it is broken, and we are not doing anything to fix it. The Internet can be affected by natural disasters, wars, governments, and surveillance. It is running out of address space and the internet service providers are not incentivized to fix it. Mesh networks, using the IEEE standard 802.11s, may one day provide a more robust and resilient infrastructure. Although mesh networking is not a new idea or a new concept, wireless mesh networking is stripping previous barriers to entry. IEEE 802.11s makes mesh networks a reality for users who otherwise would never have been able to setup such a distributed network. Applications like cjdns are making it easier than ever to create secure wireless mesh network among communities. This paper will look at the system costs associated with using cjdns. How much performance are we willing to sacrifice for ease of use and security?
Full Paper: Cost of Securing IEEE 802.11s Mesh Networks Using CJDNS[1]
npm ERR! enoent ENOENT: no such file or directory, chmod '/node_modules/sails/node_modules/anchor/node_modules/geojsonhint/node_modules/jsonlint-lines/node_modules/nomnom/node_modules/chalk/node_modules/strip-ansi/cli.js'
A temporary solution is to modify the package.json file to use a GitHub fork instead of the standard npm package:
'sails': 'github:tghastings/sails#hastings-fix',
Following this change, users should clear their node_modules directory and npm cache before reinstalling dependencies. I submitted a pull request to the anchor project on GitHub that adds the geojsonhint dependency back into package.json.
I ran into an issue using my Dell USB 3.0 dock when I upgraded to Ubuntu 16.10 on my Dell XPS-13. I was getting ~1 FPS using the DisplayLink driver. I ended up having to turn off VSync. Hopefully DisplayLink releases an update soon to fix this.
# /etc/X11/xorg.conf.d/20-intel.conf:
Section 'Device'
Identifier 'Intel Graphics'
Driver 'intel'
Option 'VSync' 'false'
EndSection
Over the last two years, I've had the privilege of developing a web application that displays real-time hardware and software information. The application utilizes middleware to communicate with drivers on different hardware platforms. When changes in values are detected from the drivers, the middleware software fires a server-sent event. The server-sent events are aggregated and then sent from the aggregation server up to the front-end client. From there, Javascript is used to parse the messages and append updates to the graphical user interface. On average, there are 29 messages sent every second. The average message size is 3KBs. Within a minute, the system generates roughly 5MBs worth of messages.