Please Don't Learn to Code via Coding Horror
While the article has it's points I think the act of learning to code is still an basic skill everyone should attempt. The actual language used can be a matter of debate but I think the importance of learning how to code is in the skill of thinking through problems step by step end to end. Of course it can be argued that this skill can be learnt in other ways like learning rhetoric for example....
The "everyone should learn to code" movement isn't just wrong because it falsely equates coding with essential life skills like reading, writing, and math. I wish. It is wrong in so many other ways.
- It assumes that more code in the world is an inherently desirable thing. In my thirty year career as a programmer, I have found this … not to be the case. Should you learn to write code? No, I can't get behind that. You should be learning to write as little code as possible. Ideally none.
- It assumes that coding is the goal. Software developers tend to be software addicts who think their job is to write code. But it's not. Their job is to solve problems. Don't celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.
- It puts the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is. Do you even have a problem? Can you explain it to others in a way they can understand? Have you researched the problem, and its possible solutions, deeply? Does coding solve that problem? Are you sure?
- It assumes that adding naive, novice, not-even-sure-they-like-this-whole-programming-thing coders to the workforce is a net positive for the world. I guess that's true if you consider that one bad programmer can easily create two new jobs a year. And for that matter, most people who already call themselves programmers can't even code, so please pardon my skepticism of the sentiment that "everyone can learn to code".
- It implies that there's a thin, easily permeable membrane between learning to program and getting paid to program professionally. Just look at these new programmers who got offered jobs at an average salary of $79k/year after attending a mere two and a half month bootcamp! Maybe you too can teach yourself Perl in 24 hours! While I love that programming is an egalitarian field where degrees and certifications are irrelevant in the face of experience, you still gotta put in your ten thousand hours like the rest of us.
I suppose I can support learning a tiny bit about programming just so you can recognize what code is, and when code might be an appropriate way to approach a problem you have. But I can also recognize plumbing problems when I see them without any particular training in the area. The general populace (and its political leadership) could probably benefit most of all from a basic understanding of how computers, and the Internet, work. Being able to get around on the Internet is becoming a basic life skill, and we should be worried about fixing that first and most of all, before we start jumping all the way into code.
Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks. Instead, I humbly suggest that we spend our time learning how to …
- Research voraciously, and understand how the things around us work at a basic level.
- Communicate effectively with other human beings.
These are skills that extend far beyond mere coding and will help you in every aspect of your life.
Getting problems and problems solvers together...
about:
The giving.github.com project was inspired by an epiphany that there is more to life than work. Coders too can actively make the world a better place!
Help root out bullying on the internet - Project Harmony
Very interesting use of statistical modeling and machine learning to track and identify a subtle an not very easily identifiable problem in social engagement tools.
Join the Project Harmony Team
The Internet is rife with hate and bullying, and the long-term ill effects of this behavior has become a hot topic in the public arena. Aside from creating psychological malaise, hostility can even affect our physical health, causing depression, anxiety, even heart disease and cancer. It may seem too big a problem for any one person to tackle, but we have created a way for everyday Internet users to help us in our mission to increase awareness of hate-speech, and thereby combat it: Project Harmony.
The Science
Project Harmony is a new suite of tools in development that seeks to improve the tenor of online communications. How? Simply put, it increases our awareness of harmful language patterns. When visiting various social media websites (currently Facebook, YouTube, Google+, and twitter) content from posts and comments are scored by a comparison to our data set. When a certain post crosses a threshold of similarity to our data its color is changed making it more salient.
Project Harmony works because at the heart of the code is a 'statistical model' built from a growing codex of bullying statements. Harmony checks each block of text and gives it a score - too high of a score, and Harmony flags that bit of text. Project Harmony is pretty clever, but still not completely accurate. We invite you to suggest text that should not have been highlighted by providing this icon: Click it once if the highlighted text is actually ‘cool’ after all.
The Software
, our Google Chrome extension, is open to anyone with an interest in making the internet safer while recognizing the real threats to human rights posed by hate speech in its many forms. Right now, all you really need is to be using Google Chrome and to install our extension, then you can contribute simply by visiting pages on Youtube, Twitter, Facebook, and Google+ where bullying comments are occurring.
The Mystery Behind Physics Engines
Physics engines in games have been around for quite a while. Games from large to small that are worth their metal have some type of physics implemented within their gameplay—all the way from AAA games such as Gears of War to casual games such as Angry Birds. Just want to give a shout out to Angry Birds Space, “that ish is bananas.” Also, another space mechanic game that was a predecessor to Angry Birds Space that is worth checking out is No, Human. The term physics can cover a broad range of topics such as the way light works or how nuclear fission is created in the core of stars. When it comes to game development, we are dealing with classic mechanics, which are based on the laws laid down by Isaac Newton. This describes the motion of macroscopic objects such as birds being shot from a sling to astronomical objects such as the effect of a planetoid’s gravity on pigs flying through space.
When a game requires real world simulations of objects interacting with one another, programmers turn to a physics engine. These engines are just large calculators that help determine the position, rotation, velocity and acceleration of game entities. But, when it comes to the internal structure of how these engines work, most game developers are at a loss. We tend to think of physics engines as black boxes that perform some magic and rarely care about the deeper implementation. Although the output of these engines are amazing to behold, it can be quite advantageous to understand its underlying mechanics. So, when one comes across anomalies caused by physics, we can dissect the causality of what is going wrong.
The underlying characteristics that determine how to deal with objects in an engine are either Mass-aggregate or Rigid-body. Some other types of physics engines that are outside the scope of this article are soft body dynamics and fluid dynamics.
Mass-Aggregate Engines: These types of engines treat entities as a collection of smaller masses. These masses are connected with a network of rigid poles. A box can be constructed with eight separate masses that link in a web to form a solid. Mass-Aggregate engines are generally easier to program, due to each mass being expressed in only linear motion. But there is a drawback to these engines: truly solid objects become hard to simulate. There is always going to be some amount of spring in your mass, so extra code is required to correct these imperfections.
Rigid-Body Engines: With rigid body dynamics, objects are based on movement in three degrees of freedom. These objects occupy space and have properties such as a center of mass, moments of inertia, and are characterized as being non-deformable. Central characteristics of these properties are motion that is defined in six degrees of freedom, which are defined by translation in three directions plus rotation in three directions. What sets this type of engine apart is their level of realism, but this comes at the cost of being harder to program.
When boiled down, a physics engine processes how and when two objects are to touch which is denoted as contact resolution. This is delegated to objects that are sitting on the floor, objects connected together and collision of objects.
The last part of the puzzle is how these engines resolve contacts, or what happens after objects collide.
You can read more at - cyborgdino.com
The Pirate Bay - The galaxy's most resilient bittorrent site
TPB LOSS
We were down a few hours earlier today. There's no need to worry, we haven't been raided this time. We're only upgrading stuff since we're still growing.
One of the technical things we always optimize is where to put our front machines. They are the ones that re-direct your traffic to a secret location. We have now decided to try to build something extraordinary.
With the development of GPS controlled drones, far-reaching cheap radio equipment and tiny new computers like the Raspberry Pi, we're going to experiment with sending out some small drones that will float some kilometers up in the air. This way our machines will have to be shut down with aeroplanes in order to shut down the system. A real act of war.
We're just starting so we haven't figured everything out yet. But we can't limit ourselves to hosting things just on land anymore. These Low Orbit Server Stations (LOSS) are just the first attempt. With modern radio transmitters we can get over 100Mbps per node up to 50km away. For the proxy system we're building, that's more than enough.
But when time comes we will host in all parts of the galaxy, being true to our slogan of being the galaxy's most resilient system. And all of the parts we'll use to build that system on will be downloadable.
Posted Y-day 20:34 by MrSpock
Yes indeed - if not the Galaxy's at least the known Galaxy's most resilient...
Solar highways.
A very cool concept, using solar panels and incorporating electronics into highways.
StatusCode Programmers' Newsletter: Peter Cooper
The weekly digest for developers ISSUE 2 - February 15, 2012 Welcome. I'm still finding my feet and you'll see new sections and tweaks come and go over the next few issues. Thanks for your support.
This issue includes some of the 'backlog' collected prior to launch so future issues will be shorter. I enjoyed everything in today's issue though, so felt compelled to share :-) - Peter.
The man has an awesome set of links here - bowled me over. If you are in the software development business and want to keep an eye on things, you should subscribe to this newsletter...
On Distributed Development
So, I have been doing distributed development at Bang the Table, for the past year. It’s a company with a very strong work from home culture. We even had a virtual birthday party for one of our directors over Skype video chat -Telecommuting / working remotely / working from home – these are various terms for an increasingly popular mode of working. In this model (of working) people use the amazing ability of the internet to communicate over vast distances instantly and modern collaborative software tools to effectively work together without actually being in the same physical room, office or even city.
There are some pretty powerful advantages to such an arrangement -
- No need for any commuting, one can stay close to one’s family (a huge factor if you have children) and flexible working hours. It is a more relaxed way to work. I have been working in such an environment for about a year now, and with a new baby, the lack of commute and the freedom to pop downstairs and help out in case my wife needs an extra pair of hands has been awesome!
- Another major advantage (at least for the company), is the reduced office infrastructure costs. In places where getting an office building thats a reasonably close to where your employees live is difficult, this can be a major boon. Also, not forcing your employees into having to commute is a major plus both for employee morale and the environment.
- One has the opportunity to hire and work with people from a larger pool rather than being limited by a single geographical location, like a city or state or even a country. This can be very powerful advantage, sometimes finding all the right people you need in a single location can be a major problem.
- An “advantage” that is often touted is that the geographical separation allows for better efficiency, since, theoretically, one could have employees coming online and starting their workday as others end theirs – making use of the entire 24 hours on the clock for work. I believe, at least for software development, this is a fallacy and attempts to leverage this so called “advantage” is a big reason for the failure of certain companies to successfully leverage this model of working – but more on this here…
The Software Stack and Latency
I love this Scale of the Universe graphic. It allows you to compare the sizes of objects in the universe from atoms to galaxies. I got to thinking about how different professions work with objects at different scales and how these professions use very different tools. A particle physicist’s tool is a particle accelerator, a chemist’s tools are beakers and burners, a wood cutter’s tool is an axe, a pilot’s tool is an airplane, a astrophysicist’s tool is a telescope.
In software we do not deal with physical objects in space. Length is not a good metric for discussing programming - rather time is the key measurement. Latency is one of the most descriptive ways of classifying systems. As with length, software latencies must be compared on a logarithmic scale. They vary by orders of magnitude from nanoseconds (10-9, one billionth of a second) to hours (105, hundreds of thousands of seconds).
A nanosecond is one clock cycle on a 1 Ghz processor. An L1 cache hit in the can be done in just 3 clock cycles, L2 in 14. DRAM is about 500 nanoseconds away. Node can respond to a HTTP request in less than a millisecond. A disk read can take several milliseconds (or worse!). Round trip ping time from coast-to-coast in the United States is 60 milliseconds. A movie download can take hours. Rendering can take days.
The “software stack” is implementations of programming platforms at different order of magnitude in latency. At the nanosecond layer we’ve chosen (largely) the x86_64 CPU instruction set. At the microsecond layer we’ve chosen (largely) Linux and C. At the millisecond layer we have several choices of dynamic programming languages.
For different goals you choose different software. If you want to make a web server quickly, Node.js on your laptop is a good choice (Darwin, X86_64). For running Node in production switching out the microsecond layer for SmartOS would be an astute choice. If however, you are building an app for Android your stack would be ARM, Linux, and Java.
Software engineers are spread through these ranges of latency. They often have a spread of latencies at which they deal with - which basically corresponds to which platforms they have access to. A web developer often will never step beyond dynamic languages - milliseconds. Building Node (a web developer’s platform) I never was forced to think in terms of a specific CPU architecture but implementing some parts in C were necessary to interface with the operating system. Kernel engineers must touch sensitive code that requires knowledge what is happening on the CPU, bus, and peripherals.
By reaching into the software stack one achieves more and more control of the system. From the browser, to POSIX, to device drivers.
People at the different layers often do not understand each other. From the slower looking at the faster - they appear to be twiggy bit twiddlers prematurely optimizing everything. From the faster to the slower - they look like lazy lumbering sloths willing to sacrifice unthinkable amounts of time for ease of programming experience.
A Swarm of Nano Quadrotors
The early glimpses of Skynet and the Matrix ??
