I spent some time over the past year tinkering with Arduinos and Raspberry Pis and had a bit of a realization: Hardware circuit components are simply the syntax for creating physical devices. As a software person, putting hardware into that context has really given it a lot of meaning.
Automating Pylint (and other Python Tasks) can be achieved with several viable python-based methods, but what if we used Gulp.js? The following code snippet gathers runs Pylint on the set of python files defined by pySource.
var gulp = require('gulp'),
shell = require('gulp-shell');
gulp.task("pylint", function() {
log('Linting with pylint -> creating report file.');
var files = [];
gulp.src(pySource, {read: true})
.on('data', function(file) {
files.push(file.path);
})
.on('data', function() {
shell.task(['pylint ' + files.join(' ') + ' -f parseable > pylint_report.txt'], {quiet: true, ignoreErrors: true})();
});
});
Notes:
This is a followup to my original post: Node.js vs Python vs PyPy – A Simple Performance Comparison. This article corrects a discrepancy caused by a slight difference in the JavaScript implementation which skewed the Node.js results.
As stated in the previous article, I’ve attempted to implement the same single-thread, brute force, recursive algorithm in many different languages. There is nothing overly special about this algorithm and I’ve made no attempts to optimize it.
Node is fast, very fast. It easily outperforms any of the other implementations I’ve included in the puzzle’s repository. As you can see by the included charts, the performance difference between Node.js and out-of-the-box Python is very significant and the difference between it and PyPy while less pronounced is significant.
When writing JavaScript, I am a big fan of minimizing functionality and variables exposed publicly, which we all know to be good practice. However, this leads to anonymous functions and functions hidden within closures. So….
How exactly do you test private methods in JavaScript? To answer that you should ask yourself, should I even be testing them independently or can I write tests for the exposed functionality and still achieve code coverage? If the answer to that question is “yes,” write tests for the exposed functionality that inherently test the underlying private functions and stop there. If the answer is “no, I really need to test this function.” There are a few approaches.
This approach involves creating member variables intended for testing and testing alone. This method relies on the build process to remove the variables before going to production. While this process works, I believe it has a code smell to it. You are polluting and bloating the code base with needless variables. If you are interested in the approach, here is an article about it.
Is the fact that you are asking this question an indicator of a code design issue? Perhaps the code is in violation of the Single Responsibility Principle? I’ve recently experienced a little epiphany associated with this. I realized that a collection of private functions that I was hiding actually belonged to a separate object as public functions. This refactoring drastically reduced the code complexity, made it more maintainable, and enabled small, important functions to be separately tested.
Building a successful product is usually complicated business. With any luck a project will have an automated deployment process. This however is only part of the equation. Another significant part would be an automated build process.
Long term success means making it easy for new people to get started in the weeks/months/years following a project’s startup. Imagine the following project in two different scenarios.
The project is a large scale application with several dependencies.
Scenario 1 (No automated configuration and build process):
Scenario 2:
Which of those scenarios is more straight-forward and easiest to work with? It’s pretty easy to see that scenario 2 is the best.
In addition to helping new team members get started, automated builds can serve as a form of long term memory.
“How do I do that?” becomes “press build.”
“How does that work?” becomes “check the build script.”
As we progress technologically, there is an increased focus on machine learning. That is a machine that is not necessarily programmed with the algorithm to solve a problem, but one that has been programmed with the ability to take a given set of input, classify it, and generate an answer. This is achieved via supervised, unsupervised, or reinforced learning techniques. My background in this field is creating neural nets and I am more that a bit rusty so for more on topic of machine learning see wikipedia. I believe machine learning to be only half of the equation to achieve true AI.
Machine learning still requires a human to create the learning data set, expected results, and training algorithm. This is an incomplete view of what is necessary to achieve true artificial intelligence.
As living, breathing creatures it is our curiosity that drives us to learn new things. It is how we learn to do anything new from walk to drive to fill-in-the-blank. I believe that Machine Curiosity is critical to the future of AI. Once we figure it out, the possibilities are endless. So this raises a good question, how do we teach machines to be curious? I don’t think that anyone really knows the answer to that question. Here, however, are some possibilities.
This is the first post in what I plan to be a series. In these posts, I will explore ideas in entrepreneurship. It’s a given that working for yourself, while it brings many risks, can bring many rewards. I believe that it is one of the only ways to achieve freedom from the daily grind and to meet long term financial goals.
My thoughts on what works will probably change a lot over time, but currently I think one of the best ways to become a successful entrepreneur is to develop applications, websites, devices, etc that are an improvement to a larger company’s product in the hopes that they buy out your company. For example, $10 million is a lot for an individual working the daily grind, but pocket change to large corporations. Buying other companies is at the heart of how Apple, Google, Microsoft, Facebook, or any other major companies acquire new technology and features so it definitely works for some people. Think of whatever your company is bought for as excellent seed money into the next. The big “but” here is don’t undersell either. If you can see a larger valuation for your company/product, stick with it and don’t take a buyout.
Apparently, writing books isn’t as profitable as you would think. If you listen to the Entreprogrammers podcast, you’ll hear just how much they make on their books. While I don’t remember the exact numbers they say, it wasn’t a lot (only a fraction of a good year’s salary). It’s enough to make me think that unless you are some big publishing company its simply not worth your time and effort.
Work is progressing on my first iOS app written in Swift. I think that I might have a rudimentary alpha product ready to start testing in a few weeks. Based on my experience with it so far, here are some of my thoughts, observations, and concerns.
<key>NSLocationWhenInUseUsageDescription</key> <string>Use location when open?</string> <key>NSLocationAlwaysUsageDescription</key> <string>Use location always?</string>
var mySpeechSynthesizer:AVSpeechSynthesizer = AVSpeechSynthesizer() var myString:String = "This is a test." var mySpeechUtterance:AVSpeechUtterance = AVSpeechUtterance(string:myString)
When executed in the iOS simulator, the code results in “Speech initialization error: 2147483665”. I’ve seen a few work arounds on the net, but I don’t believe any of them actually work in Swift.