Debugging Docker containers during development can be a real pain. The good news is that there are few great tools and techniques out there to help you get the info you need to get your Dockerized app properly running.

TLDR;

There are some really great tools and techniques out there:

• Sysdig
• Log aggregators
• Docker logs
• Docker Exec

Methods

One of the first ways you can start debugging a docker app is by simply running a container. Take for example, the redis container, you can simply run:

docker run redis

and Docker will start running the container and you will see the stdout for that container. This would be applicable for containers that have a running process defined by the ENTRYPOINT directive in the Dockerfile.

But let's say you are running the same container as a daemon (-d):

docker run --name redis_test -d redis

Now you cannot see the stdout, so now what? One quick way to see the stdout is to run:

docker logs redis_test

but this will only print out the container output up until you run that command. So you will not see what happens in the future unless you rerun the command.

If you want real time logging, Docker offers a great flag for logs, which will "attach" to the container's output (not to the container directly as described later) and display in real time. The -f flag, or follow ,lets you follow the logs:

docker logs -f redis_test

It should be noted that this technique is for containers that have a running process, as defined by the ENTRYPOINT for example. You cannot follow the logs for a container that was spun up, then ran a process then exited.

Another problem is that docker logs can be super lengthy for human reading, so one way to get around this is to output to a file then you can search that file with a tool like grep:

docker logs redis_test &> logs.txt

Should you want to debug you container by looking up a config files or maybe checking out things like /var/log or /etc/hosts, you will need a way to be able explore the container. My go to method is:

docker exec -it redis_test /bin/bash

This will actually attach a process to the container and run bash. So now you can proceed as if actually inside the container on a real terminal.

Another cool thing you can do is run a command inside the container. Let say you have a postgres container mounted to a Docker volume and you want to run a quick query on the database, but don't have any connectors, like say Datagrip or maybe a Python library. You can actually run a query using some clever hackery:

docker exec -it postgres-test /bin/bash -c "su postgres -c \"psql -d somedbname -c 'select * from users'\""

In the above example, the container name is test-postgres, we attach to the container with exec,then with the -c we log in as user postgres on the container, then use the -c bash option again to execute the psql command, and then use psql's -c option to run a query. It's like command-ception!!! The result however is a nice print out to stdout, of the query you just ran.

This example of exec and -c can be used in may other places too, where you would want to "automate" exec-ing into a container, running a command and then logging out.

Tools

There are some really great tools out there, and I won't really get into them too much since there are great tutorials out there and I don't want to repeat any work already done. So I will reference one of them for you, that is my favorite.

Sysdig
One word: amazing!

This app lets you literally dig into your host machine AND your containers with some keyboard shortcuts or mouse clicks! WOW!! Here is a link to get as taste of the power that is Sysdig, and the best part is they have a community edition: Sysdig video.

Conclusion

"With great power comes great debug-ability", said a wise uncle. Docker containers are powerful and if we don't get a hold of them during development it will make life a pain. One of the great traits of a good software engineering is to be able to understand how to debug their application, whether it's a tool, or some code.

When I started with Docker I was very frustrated with it, as I did not understand how Docker really worked. Once I discovered some great ways to exploit Docker's inner workings, like with Docker Exec, Docker became just another tool to help me build great software.

These are just a few a ways one can explore their container for debugging. Let me know if you have any cool tips or trick you'd like to share!

In September of 2015 I emailed a former business professor. I had recently registered an LLC to do software consulting and I wanted to update her on this momentous occasion. I did not yet have any customers or revenue, but was about to get awarded a contract from the USDA. I have always had the desire to own my own business and now that I officially had a business, I wanted to reach out to the professor to let her know that her teaching meant something to someone. She thought it was great and congratulated me on it.

Then a few week later she emailed again to inquire about what my business actually does. After informing her, she connected my with an MBA student who had a business idea and wanted to see if it could go somewhere. Maybe I could offer my services or maybe be a co-founder.

Enter in Carmelo Mannino.

IgnoreU’s Journey

Carmelo and I first met at a local brewery which set the tone of our professional, yet laid back relationship. Carmelo had the original idea to make a Facebook app that could filter your Facebook feed. We found out it was not possible with Facebook and pivoted to Twitter which had a much more open API. We iterated, sought user feedback and discussed over the next few weeks, and formulated a real life product we could actually implement. We went on to prototype our app idea and win various local business pitch competitions, including some at Galvanize, and at the Rocky Mountain Angel Investors. We then won money at the Colorado State University Collegiate Challenge, another business pitch competition. We won more money from the CSU venture accelerator in the form of a grant as well as their closed business pitch competition. Needless to say we were successful in the early stages. We released our beta and there it was: an app and business we could call our own.

From there Carmelo did a lot of growth hacking as we tried to get our numbers up. Unfortunately we never hit over 100 downloads on the Play or App store. We eventually slowed down and decided to call it a game. Carmelo and I official declared our business dissolved and began the process of closing down shop.

Why I did it

The main reason for pursuing this app and startup idea, even though I had a fantastic full time job, was to see what I can do, to stretch myself. I graduated with a CS degree and have always had lots of invention ideas floating around in my head. Because of this I took some business classes. I wanted to take all that business knowledge and combine it with my technical knowledge to create something, in fact I was willing to make anything! I knew it would be a learning experience and that I might not make it, in terms of being a million dollar startup, but I was ready to fail and learn while I did it.

My role

I was officially called the CTO and Co-founder, and Carmelo the CEO and Co-founder. I was the tech and Carmelo the business. For the record it was my opinion that Carmelo and I had great chemistry. We always compromised on any differences in decisions, trusted each other judgments in our field of expertise., and worked as hard as one another. Not to mention our love of brews always made things easier haha.

After prototyping our mobile app together, I began the process of actually implementing it. I receive daily Google news alerts and happened to stumble upon Ionic. It is a HTML and JS framework built on top of Cordova. Basically what it does is allows you to develop a web app, Android app and iOS app all in HTML and JS at the same time. It is an amazing framework for prototyping and non-performant-reliant apps. The first version of the app came out quick, less than a month, and was accepted widely by our various business pitch judges and our would be users.

With the making of the app itself we needed a web based backend for storing user info. For this I used some Python tools to create a web based API system. The used the Ionic built in API tools, as Ionic actually uses Angular.

A list of the technologies used:

• Ionic
• JS/jQuery/Angular
• Android Studio (for building and debugging)
• XCode ( (for building and debugging))
• Flask
• Python
• Nginx
• PostgreSQL
• AWS (Ubuntu server)
• Docker

Overall it was a simple stack. A mobile app that hit a web server with homemade APIs for data (we did minimal on phone data caching), and a database to store everything all on AWS.

What I learned

I will give a few bullet points as to what I learned then expand on a few.

• Beginning AND sustaining a startup take a lot of time, energy and emotional strength.
• You need to have an awesome co-founder/partner or else the startup will crumble quickly
• Especially in a tech startup, iterating a prototype rapidly is the key to success
• If you're not single, your spouse/significant-other will have to support the decision for you to engage alot of time with the startup, and be aware of the road they're about to go down with you
• You need a good 9-to-5 to fund your 5-to-9
• Business pitch competitions are a great way to get some early funding, so you're not spending your own cash
• You or your partner needs to be comfortable with pitching and networking
• Validate your idea before construction
• Garner as many free tools, services etc as you go along: aka bootstrap
• Growth hacking is really hard
• Failing isn't such a bad thing...

After the first prototype, making noticeable progress on IgnoreU, took a lot of time. Like I would work on a feature for a few different nights (if I had energy left after my full time job), and then all of a sudden it was Saturday again and the feature wasn't done. The problem repeatedly, was the fact that during the evenings I would only get 1-2 solid hours of coding done, which after one week is equivalent to 5-8 hours. Then maybe a solid 4-6 on Saturdays. By those numbers, I am not even working part time on the app or website. I got a prototype out really quick after locking myself away for a few hours a night for about two weeks, but that model wasn't sustainable as I had a full time job, a wife and because simply people can't work that much in the long term. So be sure to be realistic about your life and the time tables to produce the product.

We got started early on by winning pitch competitions to gain popularity and to be able to validate our idea. Carmelo also hit up our local college campus regularly for the first couple of months to get user feedback with things like notecard prototypes and surveys.

We bootstrapped our costs by doing things like using free trials of online services, using open sources software, signing up for student pricing or trials on things like AWS. Look around, companies are always offering 1 week or month trials. This is especially valuable in the beginning when your idea isn't yet validated or matured enough to warrant spending real money to progress it.

Getting users is hard. It takes a lot of creative thinking, regularly marketing via various streams (social media ads, etc) and a good product. If people actually bite on an ad the product better WOW them, or else they will never come back.

Sometimes the product can be validated, hours upon hours put into it, and growth hacking techniques fully deployed, but you still fail. This was our case. In the end, our app didn't have enough value proposition for users to switch from using Twitter to using our app. We had conversion barriers, that we either didn't test for or simply it wasn't able to be seen until actual launch. Either way, we did everything textbook though; Carmelo had an MBA in entrepreneurial stuff, I, the tech guy, had even taken business and prototyping classes. We had real world experience; Carmelo had done a startup internship and I was a software engineer with 2 years of B2B product experience. But we still failed. At first it was hard for me to stomach and I couldn't reason why or how. Like it all seemed so perfect. But after reflection, like even as I write this, it makes sense why we failed.

But we won money to fund the idea, and to even take a bit for ourselves. We lost time if you count that as currency, but we gained so much experience. We learned a lot about the real world of product development and startup life and makes me wonder how the big guys in the tech world made it to the end.

What's next?

I plan on pursuing another startup one day, but the circumstances would be different. For now though I plan to excel in the workplace. I have a shot at working at a new company and would relish the opportunity to be a part of that organization. I won't name it here, but let's just say they make a great search engine. If I don't get in there (which I am going to give it my all to get there), I might start doing some consulting on the side to accelerate student loan payoff, then start saving.

Final words

For my next venture, I would love to work with Carmelo againand if he's not available I will try my best to find someone like him. The startup I would be a part of would be able to validate rapidly and stand up quicker too because I know about my shortcomings, like what worked and what didn't because of my experience now. I would also like to be in a place where I am debt free, I have some money saved up (like 6 months worth) for personal expenses and more money saved up for the startup itself for operating expenses. I would also like to be able to devote my full attention to the startup, so that means no full time job to worry about. I know that sounds like a picture perfect scenario but, if I am going to do it again I'm going to give it my all...and succeed!

In college I concentrated on distributed systems and big data. The other options were AI, compilers or "software design" so it was an easy decision for me; the others seemed meh. Because of the classes I chose, I went on to Seagtate (a hardware company) to design analytics software for their HPC products. The system I work on is a highly distributed, microservice oriented system that processes, stores and makes available big data. Without giving away any particulars, I learned a lot about big data in production.

Utilizing 20 nodes in the school computer lab to run a MapReduce job at 8pm on a Friday, in order to benchmark an algorithm, allows you to experience the greatest of performance levels. Unfortunately just because you hit those numbers once, doesn't mean you will most of the time, if ever again, because you know, the real world! And that's what this post is about, big data in production.

When to go big data?

This is a hard questions, similar to asking when to use a JavaScript framework versus making scratch code for a frontend project, or even simpler, when do I script it out, vs writing a full blown Object Oriented program?

When it comes to big data, people get very excited, very easily. Whether it's the managers bragging about their teams big data abilities or the developer using smart words around the interns, some people look at it as an elite ability, this ability to know/process/understand/program big data. I even see data scientist regularly wanting to use things like Spark for calculations of Hive for inquiring about the data, when really a python program or a simple SQL database will do just fine (and the data scientists should know better!). Big data is still a buzzword, or phrase (since it's two words haha) and with that comes the excitement of leaning a new tool and making something cool with it.

When I first started my current project at Seagate we were using things like Spark, HDFS, Hbase, Solr, Kafka and Zookeeper. Were weren't processing a whole lot of data, but we were told that very soon we would be and that the system must be able to handle it all. Well it turned out that a year later we still aren't handling break neck data processing speed requirements but we are seeing a very necessary need for big data storage.

So back to the original question: when to go bid data? The answer is when you believe you will max out on two of the following areas: Velocity, Variety and Volume. I have seen articles on the 3 V's, 4 V's and the 5 V's of big data. I think it all can get a bit redundant so I believe you can distill it to the 3 big data V's. Again if you think you will max out on 2 of the three then you might have a big data system on your hands so get ready.

Velocity

When you are expecting to have a system with high I/O then it's time to pull out the speed demons. Things like load balances and queues. For this you can use tools like Nginx or HAproxy for load balancing and Kafka for handling high amounts of traffic.

Variety

Data variety is what relational databases have nightmares about. These are the data points you can't put into a relational database without having a sparse table or worse yet it's not even data: they're file objects! What ever will you do? You can use columnar database like Hbase or a document store like Mongo to get the job done.

Volume

When considering your 6 month data volume will you be able to handle it? Will your filesystem be able to handle it or will you have to use something like HDFS? Will one MySQL instance be enough or will you need to shard soon? If you filesystem is too small or sharding is in your future (hopefully not because of those bad tacos) then maybe starting off with a big data storage tool like Cassandra or HDFS would be wise.

The other end of the spectrum

The other end of the spectrum entails not using big data tools at all, either scubas the need is not present or because the tooling is not allowed or what have you. I have seen relational databases with well structured data (i.e. it is predictable), hundreds of millions of rows, and millions of hits a day and because of load balancing and aching tools like Redis, everything was fine. Was this a big data situation like described above? Kinda. This use case has velocity and volume maxed out, and one cold argue for a distributed database like Cassandra and tools like Kafka to queue the requests on the database , but things seemed just fine without all that.

This use case is to show that sometimes you can use normal tooling and still have two of the three big data V's. I feel that 80% of the time you can get away with just regular boring tooling. This even applies to things like frontend development where you might need just pure JS and not Angular or React.

The gray area

The gray area in our project was the fact that we were promised to receive MB's of data per minute. This means up to a few Gb per hour. In one test case I ran all our archived, un-processed data through our pipeline and because of Kafka, we were able to handle multiple GB's per hour. The real number here was 7GB of data per hour and it could have easily handled more. That might not seem like a lot, but considering how long single threaded apps would take to churn through 7GB, this is a fantastic. The problem we ran into was that our real time data processing engine was slow, as we were running two instances of the processor on Docker. So we bumped it to 4 instances and the processing time, which was preventing the Kafka queues from moving faster, was cut in half. Now making our processing time up to 14GB per hour.

After the data is processed it is stored in Hbase as file objects in addition to a columnar format, aka a dictionary (or a hashmap for you Java folk). Anyway, we used to use Solr and Lily-Hbase-Indexer to index the Hbase data. This is because Hbase can only do O(n) table scans for filtering queries. It can however do O(1) row retrieval because the Hbase master at least indexes the row keys. Solr is very fast at doing filter queries but at times we'd face instances where Lily missed some row keys and so therefore was not suitable for production level availability because it was out of sync. We switched over to Postgres for indexing and never looked back. In participial, Django was used and it was implemented in such a way that the write to Hbase and to Postgres was a single atomic transaction. This means that when the processed data is written to Hbase it must also be written to Postgres and vice versa. It's really a brilliant thing. This the beauty of not being tied to just big data tooling. Here we are using a sturdy, well known, battle tested tool, Postgres, and new fangled big data columnar database in order to accomplish the goal of making data real time. Postgres here is used in place of Solr and does a great job once all your indexes are set up.

The key take away here is don't get cornered by your tooling. In order to always have a way out, it pays huge dividends to invest some up front time in learning your tooling very well and knowing why it is exactly that you will be using it. This way you are not tied to the standard web search on how to do X, Y or Z, but instead you can create your own architectures and pipelines. This is the true meaning of software engineering and distributed systems: to compose many tools in order to create a unified system that solves a real problem and provides value.

Recap

It's a cool thing, big data. It comes with so many promises, so much potential. But it can be the downfall of the best-intentioned projects because the end solution might be too slow and lumpy to use. In order to move away from an R&D setting we must use tools that can provide us big data processing storage and delivery that seems like a non-big-data system. What you deliver in the end to a user, whether it be an API, a web or mobile app, graphs, spreadsheets, etc, it should be the tip of a very fast moving, highly tolerant, scalable iceberg. Don't be timid to mix big data tools with "regular" tools. This type of creativity is the essence of being a software engineer. So if you're gonna go big data, do it right, or go home.

Contact me for questions about your next big data project!

Bandwidth

Now that web browsers like Chrome and Firefox have made major strides in rendering and computers have achieved good processing speeds, the main concern anymore in the web development industry is not execution time but rather bandwidth cost.  No, not the cost of your outrageous internet provider (especially if you host anything from your house), but rather the time it takes to download a website and display it to the user. In fact Google favors websites with faster load times. For example a hello world (not very valuable) web page made in Java, without any valid HTML would cost you 426 byes once compiles into a class file, as compared to the JavaScript version coming out at 21 byes. That's over 20 times the amount of size. Now imagine a program that does something useful like display valid HTML, provide styling and modern functionality. With a Java program this can start adding up real quick especially after you start including graphics libraries into Java. Now of you course we have completely removed the need to send compiled programs across the wire, and that's why Apache Tomcat was invented.  So by reducing the amount of data needed for the web page and by placing the runtime responsibility on the client side we have reduced the amount of bandwidth use, causing our site to "load" more quickly.

Changes on the fly

Another things that comes up in the world of web apps is bugs; bugs that can occur in production environments overnight. Interpreted languages allowing making changes to these errors only a matter of quick edits once found. For example if a bug existed in a Python script, and you have identified the problem (which could be a task all in its own from the lack of logging) you can simply make your edits and restart the script. Again with PHP you can make the changes and allow the server to serve up the new version of the code. With compiled languages, you'd have to make the changes, recompile the code and then replace the old one. If your running your web app with an interpreted language, and you're also using Docker, then Docker will pick up the changes of the file if you are using WORKDIR. How ever if you are using a compiled executable then it's more than likely you will have to rebuild your container creating an even longer process of fixing your bugs.

Scalable

Scalability is a required component of languages used for web apps and data analytics applications (which tend to be attached to web apps for information viewing). In this case scaling a compiled language app means also scaling the technology to run the app. If you are you using Tomcat and Java, you'd also need to run multiple instances of Tomcat and store multiple copies of Tomcat on each machine, horizontally, as well as running a load balancer. Where as an interpreted language just needs to store the processor and a copy of the source. Of course a reverse proxy will be needed if doing load balancing.

Conclusion

From JavaScript and the world of objects to Python and it's unique data structures, they make building web applications easier. Of course they will never replace Java, C++ and new languages like Go in desktop applications and low level server programs. Web technologies will continue to evolve, but interpreted languages are here to stay.

• find / -type d -iname 'dir_name'

How to find a line of text in a directory (-r for recursive and l to just show the file name)

• grep -rl "text-to-search" /path/to/dir/from/root/li>

MySQL Login (-p with no spaces)

• mysql -u username -pPASSWORD -h hostname

MySQL dump to another database (-p with no spaces, databases could be on same machine or could be a remote transfer, can also transfer to a file using  >)

• mysqldump -uUSERNAME -pPASSOWRD DatabaseToExport| mysql -uUSERNAME -pPASSOWRD DatabaseNameToImportInto

Edit cron jobs (-l instead of -e for viewing the cron file, add sudo to edit the system jobs)

• sudo crontab -e

Vim controls

• vim
• x to delete
• to insert text:
• a, then chars to insert, esc when done
• shift-v to copy a whole line
• p to paste
• zero to get to the end of line, $ to get to the beginning (can use k and j also like in more)
• :wq to save and exit
• to delete whitespace (newlines, and fill with ~), use insert and press backspace

User management

• to add a user: useradd <name>
• to add a group: groupadd <name>
• to add a user an existing user to a new group: usermod -g <groupname> <username>
• to swith login status to root: sudo bash
• to switch users: su - <username>
• to allow certain binaries to be ran without root password: edit /etc/sudoers file using something like vim

The LAMP stack is the archetype of a web server. Most software engineers and even just web coders, first learn LAMP as the means for web development in the early stages. What's more, is that most of these same people continue on from the learning stages, to become experts at the LAMP stack and make careers out of knowing it. The LAMP stack is comprised of 4 components that harmoniously allow the developer to create any web software, only limited by imagination. The four components, Linux, Apache, MySQL and PHP, not surprisingly, all share common attributes that make them all such crucial components to a web developer's environment. However what is surprising, is why these components are so so crucial to the infamous stack. The LAMP stack though, is not immune; it has enemy's, vulnerabilities, shortcomings and the occasional distaste that have made other web server stack options grow in popularity in recent years.

Business Model

All the components of the LAMP stack have a unique and now popularized model for the production and growth of the software, and that is that each component is free. After taking a moment to distinguish between freeware, shareware and open source, one can see that the open source model is what has lead of the rise of LAMP. The open source business model works very well with software for many reasons. One being that users can actually support and suggest problems and defects in the product, giving the companies that support the open source the ability to find bugs and apply patches without needing to sacrifice any man hours except the ones that actually put together the patch. In turn the companies now then focus their time on releases and new features which are then redirected to the public. Take the Apache software foundation for instance and their immense success under the open source philosophy. With over 75 major projects and subprojects, like Hadoop, Tomcat and CloudStack, Apache has been churning out projects since 1999 and their release of the Apache HTTP server. Oracle has been very successful with their freeware model up until September 2014 [1] until they decided to release their source code for MySQL server. What the release means for the web development world is the continued free-ness and now open -source-ness of MySQL, deepening the metaphorical roots that MySQL has in the LAMP stack.

Big Corporation Backing

In addition to the LAMP components being open source, they are each backed by larger corporations and companies that help to contribute to their success. The Linux kernel, created by Linus Torvalds in 1989, is now the world's most popular open source operating system kernel. That success began with Linux’s open source vision which then led to the increase in Linux’s popularity. Currently, the Linux kernel is backed by companies such as Google, HP and Red Hat [2]. PHP enjoys the same big name support as the Linux kernel, dues to it being backed by Zend. After creating the first homegrown version of PHP in 1995 the founders have taken the scripting language to new heights after founding Zend Technologies in 1999. Now, Zend is a major provider of other web technologies like PHP frameworks and mobile servers, entertaining customers like Disney and Best buy. With these huge customers and their large licensing revenue, Zend can continue to update and fund R&R for PHP for years to come.

Community Support

Another reason for the LAMP stack’s success is the large amount of community support. Websites like stackoverflow, and the other stack exchange websites make it easy for people to ask questions and get help. There are numerous tutorial websites teaching on the various aspects of LAMP [3] as well as many public online videos. There are also lots of softwares that packages the LAMP components for use . For Windows, freewares like Xampp and WAMP package up each LAMP component for and include a LAMP control panel for ease of use. For linux with only a single command in the shell [4], a web administrator can have LAMP up and running in a short amount of time. Complimenting LAMP ease of installation, are operating systems built around being a web server operating system such as Ubuntu. An endeavouring area of software development resides in creating tools to support LAMP components. Each component comes with great support from the development community in order to make these tools for LAMP components. With things like MVC frameworks for PHP and GUI tools like workbench for MySQL, the management of LAMP is becoming less of a technical task as time goes on.

Weaknesses

Using the LAMP stack has it downsides and limitations in despite of its widespread distribution and popularity. Because of the high use of each of the components, news of bugs and vulnerabilities travel fast. This fast spreading news allows malicious perpetrators to then find out the causes of the bugs in order to create attack kits and methods in order to attack the outdated systems before the bugs can be patched. Even more security vulnerabilities come up with the use of GUI management tools for MySQL and Apache. Tools like phpmyadmin and webmin allow ease of use for novice and intermediate users, but also create remote access vulnerabilities in the event of a bug. Another downfall of PHP is that is has no built in security; it is a language similar to C where it allows a lot of freedom, but it comes at a price. Security in PHP can only come in the form of good programming or PHP frameworks. One another downfall to mention about LAMP is its problem with scaling up. MySQL has good scaling out capabilities with the use of MySQL Cluster, but because of its relational nature sharding can be very difficult making it challenging to extend a website's features as in Facebook’s case [7]. Additionally MySQL’s ACID feature cause lots of overhead for small, multi-user transactions and increasing traffic will only cause server processing to increase linearly. Apache has the downfall of not dealing with streaming as well as it’s competitor Nginx [5]; therefore it’s strengths lie in stateless transactional serving.

Conclusion

With apache serving up over 64% of all the website currently on the internet [5], and PHP developer jobs making up 25% of all software engineer jobs posted on Linkedin [6], the LAMP stack will have long term presence in the web software industry. With awesome attributes, like free and open source, cross platform compatibility and community support the LAMP stack can a part of any successful web software project. Even though LAMP has weaknesses like scaling any vulnerabilities, just like any other software stack has, LAMP continues to be supported, used and extended by novice up to expert developers alike. As the world continues to move toward cloud based software, the LAMP stack, as old as it is, has a bright future in the web development industry.

References
[1] https://github.com/mysql/mysql-server [2] https://www.kernel.org/ [3] http://www.w3schools.com/ [4] sudo apt-get install apache2 mysql-server php5 php5-mysql [5] http://venturebeat.com/2012/06/18/nginx-the-web-server-tech-youve-never-heard-of-that -powers-netflix-facebook-wordpress-and-more/ [6] https://www.linkedin.com [7] https://m.facebook.com/notes/facebook-engineering/mysql-and-database-engineering-mark-callaghan/10150599729938920

• update [table_name] set [table_column] = concat('[start_tag]', [table_column], '[end_tag]') where id > 0 and id < 10;

Search and Replace

• update [table_name] set [field_name] = replace([field_name],'[string_to_find]','[string_to_replace]');

IgnoreU

C Projects

Chat program

This is a simple socket program that allows two users to talk to each other using network programming. Run './chat -h' for usage. Contact me for the source code. The binary for linux can be downloaded here. Note: this was compiled on Linux Fedora.

Cipher

This is a simple block and stream cipher program. For the block cipher it swaps one bit with the one next to it. For the stream it XOR's a bit stream with a key. To encrypt, run the program with the proper arguments (./cipher for usage). Then to decrypt run the program again on the output file. This works for both the stream and block cipher. Email me for the source and get the Linux Fedora compiled binary here.

It took me a long time to decide on a home network architecture that was both scalable, usable and practical. When I say scalable I mean, horizontally (adding more resources). When I mention usable, I mean I want the technology to be a go-to environment, one that I always want to use and am willing to recommend. And when i talk about practical I mean it's open source, cheap and reliable. The cluster should also be secure and easy to backup.

The host

Taking some of these things into consideration, my first draft of this architecture was to run Windows Server 2012 with the hyper-v feature. Then using the hyper-v feature I tried running things like CentOS-7-min as a guest. I quickly found out that hyper-v doesn't allow you to port the virtual machine image easily. After discovering this I changed my mind to run windows 8.1 with VirtualBox. I have 12 GB of RAM, 1.2 TB storage and an AMD FX processor in my machine so I am able to have many machines at once. Despite many colleagues disliking Windows 8, I actually like it. I could have selected another host OS like CentOS-7-full but I went with Windows. Besides as a student at CSU we get basically any Windows software for free.

The guests

I have a VM as a template for all my different needs. For example I have a VM with ubuntu server 14 (which is CLI only), and it only has the OS installed and the updates from when I installed it (along with the server software i chose to install like MySQL and apache). Basically I can turn it on and then point to it on a web browser in my home and see the apache welcome page. Then from this template I clone it in order to make production or development environments. This way I can blow up an entire machine, delete it and then just clone again when I want a fresh one. I't pretty sweet. In addition to my ubuntu machine I have another ubuntu machine with a python, django and postgreSQL stack setup on it. This one is mostly for experimentation. A third one I have is a CentOS min template that I use for things like running hadoop clusters or mysql clusters.

Final thoughts

I think once a developer gets to a certain point they should look into virtualization - for everything! It truly is amazing to spin up a machine, alter it into an oblivion and then just delete it if you break everything. For example you can see what happens when you run "sudo rm -r /". Warning - do not run this on your home machine! VirtualBox is really cool because now it enables you to do open source development easily because now you can get a project's environment up and running in like 5 minutes by using things like vagrant. Also VirtualBox allows you to save VM images in different formats so you can port a VM to your friends VMware setup. At the very least having a home cluster has saved me money on cloud services (domain name required), allows for some cool development environments and taught me a bunch!

Let me know what stacks or configurations you use in the comments!

PROS

• quick message dissemination
• redundancy of internet components
• people use internet more than TV

CONS

• implementation resistance
• abuse from hackers
• the internet is somewhat fragile

I'm sure there are other disadvantages I'm not thinking of but think this is enough for now. I doubt this will ever be deployed but I think this is how the internet and the computing industry got built: someone had an idea posted it in writing and asked for some comments about how to improve it (reference to RFC's). Let me know that you think in the comments below.

Yii is not intuitive at first; it takes some time investment up front, learning the framework using tutorials. There are tons of free online documents as well as books available. I just looked up some tutorials on YouTube and followed along by creating a simple instance of Yii on the server at work. After learning the system and the syntax, Yii became a matter of learning the available plugins and features; And not plugins like WordPress.

A prerequisite to learning Yii is to know basic software development concepts one of them being model-view-controller. That's all that Yii is based on. If you know what an mvc is pretty well, you can latch on to the Yii structure, after that the Yii syntax. I would recommend it to some one else but the downside to this recommendation is that I haven't work with any other frameworks before. I don;t c and java libraries count, although some (people on the internet) argue this they count.

I'd like to check out some other PHP frameworks to see what they have to offer. Let me know if you have any experience with another PHP frameworks or what you think about Yii if you've used it, in the comments below

It seems lately that there is much turmoil and heated debates about religious profiling.The events in the middle east have made it so that the non-Muslim people living there, cannot live there anymore without persecution. Because of this many countries, like the US are accepting these people as refugees. Some of the political groups in America however are not supporting the collective American decision to accept these refugees, because of the fact that many of the refugees are Muslim. This has given way to much debate about not only the ethnic persecution that was supposed to have been gone from America, thanks to people during the African-American Civil Rights Movement, but also the religious persecution.

In the midst of these times I feel it is easy to become excited for one side or another and to say things and believe things that later might be regretted. So because of that I personally must remind myself what I believe and why I believe in it. I took some time to remind myself of why Christianity is the religion I know to be real and correct and why I’d even call myself to be a follower of Christ.

So how do we know Christianity is real?

The basis of the religion

God loved us even before the sacrifice

The spirit is in us, not around

The contrast with other religion

It’s all about love

Conclusion

I do believe there is a right or wrong here just like some of the other religions believe that their religion is the “correct” one. I don’t think that followers of different religions should let this be a means for conflict though. Instead we should challenge each other, ask questions and write out our beliefs so that others may find out others’ ways of thinking. Archaeology and other forms of science can’t prove that the bible was inspired by God himself, that’s for you to decide: Is Christianity real?

The best way to answer this question is from my own standpoint then I'll point to a source that I think best says what a Christian is. Personally I think a Christian is anyone who:

• Believes the Bible word for word, front to back and believes that it is absolute truth. (John 17:17)
• Believes that the only way to salvation is through Jesus Christ, the son of the living God (John 14:6).
• Believes that God speak/works/lives through/in us via the Spirit (Romans 8:11)
• Believes that God is One and Three living as a divine trinity - In Nomeni Patri Et Fili Spiritus Sancti. Boondock Saints anyone? (Isaiah 48:16)
• Believes that to truly take on the title of Christian you must live your life as a disciple of Jesus Christ, this means putting all the above listings into practice (James 2:14)

There's alot of believing in that list, but I guess that's why it's called faith (Hebrews 11:1). I put this into list form because I feel that lists are measurable. And that a Christian can be only on or off, not luke-warm. According to what the bible says, being a true Christian is measurable in two (but not limited to two) places:

• John 14:6: Jesus answered, "I am the way and the truth and the life. No one comes to the Father except through me.
• Revelation 3:16: So, because you are lukewarm, and neither hot nor cold, I will spit you out of my mouth.

So to me these mean that my Christian checklist is pretty accurate and that no one but God, through his word and his Son, can determine what constitutes what a Christian is. The bible is full of places that tell us how to live out our faith, and if we're not firing on all cylinders, can we really call ourselves Christians? I don't think so, because it was said so clearly by God in Revelation that we must daily be accurate and on fire about our faith in order to honor God in the way that pleases him the most.