How to put together a CV or résumé that will get you hired - specifically how to talk to the different groups of people who will be reading your CV. Although it's Perl-focussed, it should be generally relevant...

Original Post - http://www.slideshare.net/perlcareers/how-to-write-a-developer-cvrsum-that-will-get-you-hired

Nice feedback, will definitely start working on it.

Computers process information based on electrons—particles representing binary bits via their respective charges. These electrons are shuttled around microprocessors and memory banks via conductive "wires" rendered incomprehensibly small thanks to nanoscale lithographic techniques. In the grand scheme of information, however, those pathways are still enormous, like building subway tunnels for cockroaches.

A reasonable next step beyond electrons and electricity, generally, would be optics: information via photons, or light particles. This is a possibility—or perhaps inevitability—being aggressively researched by physicists and materials scientists. According to a paper published Friday in the journal Nature Communications, computing may be one step closer to the photonic information age with the apparent resolution of one of the technology's deepest problems: fine-tuning the electrical conductivity of glass.

"The challenge is to find a single material that can effectively use and control light to carry information around a computer," noted Richard Curry, the current study's lead investigator and a physicist the the University of Surrey, in a statement. "Much like how the web uses light to deliver information, we want to use light to both deliver and process computer data."

"This has eluded researchers for decades," Curry said, "but now we have now shown how a widely used glass can be manipulated to conduct negative electrons, as well as positive charges, creating what are known as 'pn-junction' devices."

NOW WE HAVE NOW SHOWN HOW A WIDELY USED GLASS CAN BE MANIPULATED TO CONDUCT NEGATIVE ELECTRONS, AS WELL AS POSITIVE CHARGES.
The p-n junction problem arises from the nature of semiconductors known as extrinsic semiconductors. These involve materials that have been "doped" with some other material, or impurity, to give the semiconductor a particular conductivity property. The new impurities change the electron landscape of the material being doped, either adding or subtracting electrons and electron holes (empty slots within the orbits or electron shells of given atom that might otherwise contain a particle).

Getting the right sort of conductivity for optical information devices has involved both the usage of very high levels of doping agents and very high temperatures. This is true, in particular, for a material called chalcogenide glass, the preferred medium for photonic integrated chips and other optical computing applications.

Chalcogenides act as so-called network solids, in which a macroscopic material acts as one large single molecule. This sort of material has the advantage of being able to conduct light across a relatively wide range of bandwidths, while chalcogenides have unique properties allowing for the usage of electron beams to control the optical refraction of a material, among other handy things.

The catch is that chalcogenides are p-type conductors. That is, they're characterized by more electron holes than electrons, with the "p" referring to the positive charge of the holes. The problem here is that they resist interfacing with the other variety of extrinsic semiconductor: n-types. So far, it's been extraordinarily difficult to dope a chalcogenides glass to act as a n-type semiconductor.

"Electronic applications [of chalcogenides] are limited as a consequence of their almost universally unmodifiable p-type conductivity," the current study notes. What's more, the authors add, the only existing modification technique, involving high temperatures and high concentrations of doping agents, is incompatible with current integrated circuit manufacturing techniques. So we're stuck with electrons.

Or at least we were. Curry and his team have for the first time successfully doped chalcogenide glass in such a way as to allow for standard-ish integrated circuit manufacturing involving non-extreme temperatures and relatively small amounts of doping agents. The process involves the implantation of ions of the element bismuth in the glass in concentrations of only .6 percent of what was previously needed.

The result is a material that's highly refractive, thermally stable, and that requires just a tiny fraction of the electronic current needed to maintain optical information, compared to other materials.

Curry expects the technology to be built into common computers within 10 years, and, well before that, a long in-development computer memory technology called CRAM. CRAM is essentially where a chalcogenide glass has its phases swapped around between crystalline and amorphous with the application of heat. In terms of speed, CRAM could potentially beat out current hard drive technology (including Flash memory) many thousands of times over.

Original Post - http://motherboard.vice.com/read/within-10-years-computers-will-process-light-instead-of-electricity

Everyone needs a little help sometimes, even the pros. It’s hard to remember every single little detail. Every once in a while you end up searching for basics that you have momentarily forgotten. What a waste of time that can be. So, we searched for and collected some popular design cheat sheets to help you through your day. Take a look.

Original Post - http://blog.placeit.net/10-awesome-uxui-cheat-sheet/?utm_content=buffera203b&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

I’ve been spending a bit of my time playing around with new languages — in particular, Rust has captured my imagination. The bulk of the code we write at Chef is in Ruby, Erlang, and Javascript (lately Angular.) There are things I like about all those languages:

Ruby feels like it always hits the “whipuptitude” part of my brain. It’s easy to simply sit down and start typing, with very little in the way. It also has the expressiveness that I always loved in Perl. The more you understand the language, the more it feels like I can express myself in the same way I do with English.
Erlang and OTP are glorious to operate. Things like pattern matching, actor concurrency, single assignment, and a lovely runtime make it a joy to run, manage, and debug production services. I think the syntax is awkward, but it too has a terse kind of beauty when you soak in it.
Modern Javascript is becoming delightful in its own way. The ease with which you can grab community packages and frameworks, the sheer expressiveness of things like Angular, and the progressive slimming down of the often used parts of the language make the experience delightful again. It used to feel awful to me.
So — I decided to write a little Rust and, because everyone in my world seems swoony over it, Go.

Rust
I started paying attention to Rust a couple of months ago. The language is designed to fill the same niche as C/C++ — suitable for low level programming, with high safety guarantees, and a novel approach to memory management (borrowing). It also has a bunch of language features that I love from Erlang — pattern matching, actor style concurrency, immutable variables.

My history with C/C++ is limited — to be honest, my history with any strongly typed language is limited. As a systems administrator, there just was rarely a reason to do more than patch someone elses code (which I’ve done plenty of — but a patch isn’t the same as writing something from scratch.) In the few experiences I’ve had, I found the compile->run->segfault loop to be deeply irritating. I recognize that this is my own ignorance on display: if I spent more time in the language, I would certainly come to understand the pitfalls that were so regularly striking me.

So it was that I set out to re-write a command line utility from Ruby to Rust. I have no intention of shipping it, or even really sharing it — it was just an excuse to learn the language. Here is what I observed:

Cargo is nice
Cargo as the front-end tool to Rust projects is coming along super nicely. Creating a new Rust project, adding in testing, dependencies, etc was easy and super clear.

Expressive like a scripting language
Rust can be quite expressive in a way that feels like a low level scripting language. Check this out:


https://gist.github.com/adamhjk/e296257b32818ee8691d.js
While things like as_slice() and Vec<String> might take a little explaining, but it’s remarkably straightforward. Here is the review function:


https://gist.github.com/adamhjk/ead9de51d6f6d3aefeb2#file-review-rs
Again, I don’t think this is any more difficult than it would have been in a scripting language. It takes a little getting used to the fact that, for example, I return an Option<Path> from have_dot_git(cwd), and use pattern matching to extract the value (or raise an error) — but once you realize whats going on under the hood, it’s pretty great.

Strongly typed
In every other language that was strongly typed, I always felt like I was in a wrestling match with the compiler. I found it exceedingly difficult to trust that it was stopping me from doing something stupid, rather than getting in my way. (I recognize this is an emotional flaw of my own) Rust felt different for three reasons:

Its error messages are exceedingly clear, pointing you directly to what is going wrong, and often showing you the precise solution. (“Did you mean…”)
The compile loop was very fast, and when my code compiled successfully, it always ran exactly like I wanted it to.
The idea of borrowing, and the idea of lifetimes, takes some getting used to. However, the compiler really is acting in your best interest all the time, and again the error messages and rules are clear. There is no traditional garbage collection in Rust — but it has very clear rules for how long things on the stack and heap will live. Those rules tie closely to scoping, in a way that feels really natural.
Most importantly, for me, my code never segfaulted or panicked. This was an experience that I’ve never had in my life when working with a low level systems programming language. If the compiler accepted my input, it ran — fast and correctly. Period.

Libraries don’t really exist
Rust is still evolving, heading towards a 1.0 release. As a side effect, a lot of the higher level libraries just don’t exist, or haven’t been written. A good (trivial) example was a great command parsing library just doesn’t exist yet. There is one included in the standard library, but the interface is clunky at best. A few promising libraries existed on Github, but the best one (from an interface/functionality point of view) failed to compile on the latest version of Rust. (This was due to the fail!(..) macro being renamed to panic!(..) — not a big deal, but a sign of the kind of things that are still evolving.)

Similarly, Cargo is great at fetching dependencies — but there isn’t a collection of what is available, a-la NPM, Rubygems, or CPAN.

Final Thoughts on Rust
Rust is a powerful, deeply well thought out systems programming language with a pretty amazing and useful set of features. (Generics, Traits, Pattern Matching, Actor concurrency, Borrowing — the list goes on) There is a tax on learning the surface area and “Rust Way” of solving a problem — the language itself is simple, but has lots of different concepts to wrestle with.

That said, its the first time in my life I feel like I could trust myself to write fast, efficient, low level systems code. The compiler was your buddy, and the errors it fed me were useful and clear. When the language hits 1.0, and the ecosystem of libraries starts to heat up — Rust is going to be a force to be reckoned with.

Go
Lots of people have said lots of things about how amazing Go is. After spending even a few hours re-building something in the language, I see the appeal.

Go is small
You can learn the surface area of the language super quickly, assuming you have ever programmed in anything C derived. There are pretty much only the things you already know how to use in the language: if/then/else, switch, for. They use the syntax you already know. They provide short hand for things that you could type verbosely, but don’t want to (:=, for example).

Go is opinionated — about lots of things
When you read How to Write Go Code it starts with telling you how to lay out the top level source directory for everything you will write in Go. The Go tooling knows how to take that structure and do the right thing with it — compile binaries that go into your ‘bin’ directory, run your tests, grab dependencies.

The static output is nice — and the reality that, whatever you compiled locally will be what your users consume feels great.

Go gets out of your way
Where the Rust compiler made sure that what I expressed would result in working low level code, Go sits in the middle. The language is strongly typed, but in practice it seems to infer what you mean most of the time. For example:


https://gist.github.com/adamhjk/5a475b8dd45971a4e814#file-dot_git_dir-go
The only type annotations in that function are the inputs and the outputs — everything else just works. It feels fast, easy, approachable and very low hassle.

Go failed at runtime
It was very, very hard to get Rust to fail at runtime. The compiler made sure I checked every code path, always made sure I covered every angle. Go was more than happy to do what I told it — while the compiler would stop me from being egregiously stupid, it wasn’t going to stop me from doing something like this:


https://gist.github.com/adamhjk/9c7eae1d053a1788f581#file-panic-go
Where line 9 there just blindly assumes the regex found a match, and causes quite the run-time error message. This was impossible in Rust:


https://gist.github.com/adamhjk/2eb74d326242a9093f9e#file-current_branch-rs
Because the return of my regex capture as an Option, the compiler knew I needed to deal with all the possible values. I literally couldn’t choose to ignore it. This happened when I wrote the code — in Go, I just wrote what I thought I wanted, then learned about my mistake at runtime (and it’s a trivial fix.) In Rust, the compiler told me when I first tried the function that I hadn’t dealt with the None result of my Option<Capture> return.

Speed, accessibility, and libraries
The trade-off is interesting. The Go code took far less time to write, the language was so accessible, and the ecosystem was strong. It let me work like I would have in a scripting language, while stopping the most egregious kinds of errors. Because the only language constructs are the most common constructs, it took no time at all to feel facile in the language.

Go had a huge library ecosystem, a clear way to find them, and an easy way to get them.

So.. Rust or Go?
The pragmatic answer is ‘horses for courses’, I guess. Go could clearly fill the same niche that people write Ruby, Python, or Perl for. It’s an easy, approachable language with a strong and fabulous ecosystem. I see why people love it. Static binaries, great ecosystem. Kind of a layup. I wrote the Go code probably twice as fast as as the Rust code.

The thing is, I liked Rust more. I like that it has pattern matching, generics, immutable data by default. I liked that if my code compiled at all, the odds that it did what I wanted were extraordinarily high. When I think about what an ecosystem built on those fundamentals would be like, I want to live in that world. It’s better than the world I live in on languages I already have an affinity for for a wide range of use cases, and lets me play in a space I haven’t really ever felt comfortable in. I’m pretty sure the advice that Rust is amazing where you would use C/C++, and Go is amazing where you would use Ruby or Python is true. However, I think once Rusts ecosystem takes off, it will start being a great choice for the Ruby/Python niche as well.

I was reminded of a lesson I learned about executive hiring — rule number one is that they have to be amazing at something. Someone who is just “good” at everything won’t, in general, actually turn out to be great. Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. Rust is absolutely amazing at ensuring the code you write is correct and safe at runtime — it’s a revelation.

You should definitely give both a try.

Original Post - https://medium.com/@adamhjk/rust-and-go-e18d511fbd95

More working, useful code has been written in the Java programming language than in any other in history, with the possible exceptions of C and COBOL. When Java was released almost 20 years ago, it took the software world by storm. It was a simpler, safer, alternative to C++, and some time later its performance caught up, too (depending on the exact usage, a large Java program can be slightly slower, as fast, or a little faster than a comparable C++ codebase). It offered truly tremendous productivity benefits over C++, while sacrificing very little (if anything at all) in return.

Java is a blue-collar language – the working person’s trusty tool – adopting only tried and true idioms, and adding features only if they solve major pain points. Whether or not Java has stayed true to its mission or not is an open question, but it certainly tries not to let current fashions sway it too far off course. Java has been used to write code for anything from smart-cards, through embedded devices, and all the way to mainframes. It is even being used to write mission- and safety-critical hard realtime software.

And yet, in recent years, the Java programming language has gained some noteriety as well, especially among web startups. Java is verbose relative to languages like Ruby or Python, and its web frameworks used to require extensive amounts of XML configuration, especially when compared to configuration-free frameworks like Rails. In addition, Java’s widespread use in large enterprise companies led to the adoption of programming patterns and practices that might have a place in a very large programming team working for a company with extensive bureaucracy, but do not belong in a fast-moving-things-breaking startup.

But all the while, Java has changed. The language recently acquired lambda expression and traits; libraries provide it with true lightweight threads – just like Erlang’s and Go’s. And, most importantly, a more modern, lightweight approach now guides API, library and framework design, replacing all the old heavyweight, XML-laden ones.

Another thing has happened in the Java ecosystem in the past few years: a bunch of good implementations of alternative languages for the JVM have started gaining popularity; some of those languages are quite good (my personal favorites are Clojure and Kotlin). But even with those languages as viable (and sometimes recommended) options, Java does have several advantage over other JVM languages, among them: familiarity, support, maturity, and community. With modern tools and modern libraries, Java actually has a lot going for it. It is not surprising, thenrefore, that many Silicon Valley startups, once they grow a bit, come back to Java, or, at the very least – to the JVM.

This opinionated, introductory guide is intended for the Java programmer (all 9 million of them) who wants to learn how to write modern, lean Java, or for the Python/Ruby/Javascript programmer who’s heard (or may have experienced) bad things about Java and is curious to see how things have changed and how they can get Java’s awesome performance, flexibility and monitoring without sacrificing too much coolness.

The JVM

For those unfamiliar with Java terminology, Java is conceptually made of three parts: Java, the programming language, the Java runtime libraries, and the Java Virtual Machine, or JVM. If you’re familiar with Node.js, Java the language is analogous to JavaScript, the runtime libraries are analogous to Node.js itself, and the JVM would be analogous to V8. The JVM and runtime libraries are packaged together into what is known as the Java Runtime Environment, or the JRE (although often when people say “JVM” they actually mean the entire JRE). The Java Development Kit, or the JDK, is a version of the JRE that includes development tools like javac, the Java compiler, and various monitoring and profiling tools. The JRE comes in several flavors, like those made for embedded devices, but in this blog post series, we will only be referring to the JRE made for server (or desktop) machines, known as Java SE (Standard Edition).

There are quite a few implementations of the JVM (or the JRE) – some are open-source and some are commercial. Some are highly specific: for example, there are JVMs for hard-realtime embedded software, and those made for huge RAM sizes (in the hundreds of gigabytes). But we will be using HotSpot, the free, “common” JVM implementation made by Oracle, which is also available as part of the open-source OpenJDK.

Java was built for the JVM, and the JVM was built for Java (recently, though, the JVM has undergone some modifications specifically with other programming languages in mind). But what is the JVM? This talk by Cliff Click explains what the JVM does, but put simply, the JVM is an abstraction-implementation magic machine. It takes nice, simple, and useful abstractions, like infinite memory and polymorphism – which sound costly to implement – and implements them so efficiently that they can easily compete with runtimes that don’t provide these useful abstractions. More specifically, the JVM has the best garbage collection implementations in widespread production use, and its JIT allows it to inline and optimize virtual method calls (which are at the core of the most useful abstractions in most programming languages), making them extremely cheap while preserving all of their usefulness. The JVM’s JIT (Just-In-Time compiler) is basically a highly advanced profile guided optimizing compiler running concurrently with your application.

The JVM also hides many of the idiosyncracies of the underlying hardware/OS platform, like the memory model (how and when code running on different CPU cores sees changes to variables made on other cores) and access to timers. It also offers dynamic runtime-linking of all code, hot code swapping, and monitoring of pretty much everything that’s going on in the JVM itself, and in the Java libraries.

That is not to say that the JVM is perfect. Right now its missing the possibility to embed complex structs inside arrays (this is scheduled to be resolved in Java 9), and proper tail-call optimization. Nevertheless, the JVM is so mature, well-tested, fast, flexible, and allows for such detailed runtime profiling and monitoring, that I wouldn’t consider running a critical, non-trivial server process on anything else.

But enough theory. Before we go any further, you should download and install the latest JDK here, or, if you prefer, use your OS’s package manager to install a recent version of the OpenJDK.

The Build

We will start our tour of modern Java with the build tool. Java has had several build tools over its longish history (Ant, Maven), and yes, most of them were based on XML. But the modern Java developer uses Gradle (which has recently become Android’s official build tool). Gradle is a mature, heavily developed, modern Java build tool, that uses a DSL built on top of the Groovy language to specify the build process. It combines the simplicity of Maven with the power and flexibility of Ant, while throwing away all that XML. But Gradle is not without its faults: while it makes the most common things easy and declaratives, there are quite a few things that are quite, though not very, common, but still require dropping down to imperative Groovy.

So let’s create a new modern Java project with Gradle. First, we’ll download Gradle here, and install it. Now, we’ll create our project, which we shall call JModern, by first creating the jmodern directory, changing into that directory, and running

Original Post - http://blog.paralleluniverse.co/2014/05/01/modern-java/

omeizaowuda:
Hello, I am a Front End Web Developer. I also do UX/UI Design too. I barely come over here to nairaland, but when I do. All I hear about is Java, Programming, c++, etc. No one talks about the great javascript and its frameworks (angularjs, nodejs) or its perfectly compiled library(jquery). People don't also talk about the beautiful features of html5, and css3. I am a hungry front end developer. I design everyday, I do UX/UI work too, most of which are freelance. I want to know, is it that you guys are not interested in it or what is the problem. Currently I teach, and I do it for free. I am building a ui for a design blog I want to build for my naija people. Just as research is the first principle of good ux. I need to know what the problem is. Why do we care less about good design but care too much about functionality?

I can't speak for others, but there are 2 things I want you to please consider.

1. There is a special thread for web designers, web developers at - https://www.nairaland.com/webmasters . More than likely you'll find people talking MORE about web development and web designing over there than here in this thread. People 4get that Web Designing & Web Programming ARE 2 DIFFERENT THINGS. I personally can program any web site but I can't make a good web design. I'll need a design to rely on because Im not creative when designing websites.

2. I might be wrong but I've personally noticed that from creating new threads, there seems to be mostly 2 types of people on Nairaland's Programming Sections that look at my threads and respond. There are others but mostly 2 types of people respond. The 1st type are either beginners/novices and are trying to get in the game . Some to make money (which I understand) and some to learn, but mostly to make money quick and easy. These people ask questions like 'So where can I get this book?' 'Is Java or Python better?' 'How long will it take me to get this done?' 'What do I need to make an app like ____?' N then there is the 2nd type, they are the experts/veterans who really know what they doing. They've been in this game for years and can tell you the best tools to use and have tested/experimented with different things. These people leave responses like "If It wasn't for Linus, you wouldn't have an open source computer talk less of a smartphone', 'Python is a better programming language for APIs' n then they post APIs or other work they've build with Python. In other words, the experts/vets talk shit and then they back it up work of their own so that people can use to their stuff or promote it. But then they argue back n forth.

With that said the beginners/novices are not worried about the details as of now bcuz they need money to survive and live with the small amount of time that they have, while the experts/vets already know the details but are focused on other things. I might be wrong, but that is what I've noticed.

I can't speak for every college in the world when I say that a computer science curriculum, and by extension academia in general, leaves one sorely unprepared for the workplace.

Okay, maybe that was a bit unfair. But having been a computer science major for the past three years -- one semester of which was spent as a teaching assistant for intro-level students -- I was, shall we say, taken aback when I interned at a large tech company recently. This is what they expect? I learned none of this in school!

Like I said, I can't speak for everyone; maybe if by some odd twist of fate I had gotten accepted to a prestigious tech school instead, I would have been bestowed with everything I needed to retire from my successful startup at age 25. Still, the hallowed halls of education are a far cry from the industry no matter where you go, and if we are to make the brave transition we're going to need a whole lot more help.

If I could jump back in time to freshman year, here are the four things I would have wanted to learn most.

Version Control Systems
I am for obvious reasons biased towards git, but whatever the VCS, a graduate should know how to manage their code not only alone but as part of a team. This concept should be introduced fairly early, maybe even in the second semester.

At that point a student is probably still learning their first language: having covered Java's syntax and basic control structures in the first semester, for example, they would move on to data structures and common algorithms (sorting, etc.). This is by no means a good time to drop the "complexity" of a VCS on anyone, which is why at first it might be a good idea to simply introduce it as a new way to turn in assignments.

Imagine the following scenario: your teacher shows your a "website" (GitHub repo in disguise) where you are to turn in all assignments -- naturally the students have already been added as contributors. On the first day of class you were given a step-by-step walkthrough of how to install git. Then your teacher shows you how to git commit and git push. "Remember those two," you are told again and again. And you do, because how hard is it really to remember two words? So for an entire semester that's how you turn things in. You finish your assignment, you open up that little window called a "terminal" to type two commands, and it automagically appears on the teacher's website.

By the time higher-level courses roll around...surprise! You were using this thing called a "version control system" all along. Oh, and look at all the other cool stuff it can do! At that point, students should participate in a group project where committing is part of the grade. When they mess up and cause all sorts of hilarious merge conflicts -- and they will -- resolving them becomes part of the learning process.

NOTE: Yes, I realize a single repo for all students is just asking for plagiarism to occur; some savvy student could git pull at the last moment and have the keys to the kingdom. Surely there's a better way, but for now we'll assume everyone is an angel.
Right now my university regards VCS as something students should learn on their own. Here's why that needs to change:

[Insert some number really close to 100% here] of tech companies use some form of VCS internally, and they're not going to bother teaching new employees how to use it
Most students are notoriously good at avoiding extra work
Students not only need to learn, but learn well
As an illustration of that last point, consider these commits:

Bad Commits

These were made by a teammate of mine on a course project I'm currently working on. Anyone with any experience using git is probably trying to claw their eyes out right now, and for good reason. But how is my teammate supposed to know that such a thing as "commit etiquette" exists?

That's right. By being taught.

Testing
I remember writing JUnit tests for a college project. It was in my junior year, the sixth semester no less, and we weren't even taught how to use JUnit. It was another one of those "learn it on your own" deals.

That's cool. I have no problem learning how to use a testing framework on my own, and in fact teaching yourself things is an incredibly valuable skill (more on that later). But in that case why go to school at all? We pay for a college education not to screw around for 1500 days of our lives, but to learn the important stuff.

Testing is important.

The problem is that school assignments are not well-suited for testing. Consider the archetypical example: writing a program to calculate the nth Fibonacci number. It's a great assignment to throw at students learning a new language because it's so simple, meaning students can focus on adapting the algorithm to an unfamiliar syntax; I've done it in at least 3 different classes already. Here's a Python version courtesy of Rosetta Code:

def fib(n):
if n < 2:
return n
else:
return fib(n - 1) + fib(n - 2)
You could write a test suite that makes sure this works for fib(0) and fib(1) and assorted other values like fib(15). In fact, this would be a great way to make sure you get an A, since if your program passes all your tests then of course it's correct, right? (If you answer yes, I pity you.) Arguably, however, it would also be a stupid test.

The other typical example is the assignment on writing getters and setters for properly encapsulated Java classes. Ooh look, I set x to 19 and when I called getX() it returned 19! Success!

In practice tests are never that simple. There are all sorts of considerations like mocking objects, functions, and return calls, finding edge cases, linting, etc. This requires a project complex enough to warrant these testing concepts, and I wouldn't expect to see such a project in most of my classes. One plausible solution is to give students a fairly large completed project that has errors riddled throughout, and task them with writing tests to uncover and subsequently fix the errors.

How to Google
Let's try a little experiment, shall we? When I say go, you try answering the question below as quickly as you can with working, compilable code. Ready? Go:

In Java, how do you read a file line by line and print out every other line?
If you instantly knew how to structure the code to read in a file, kudos to you, here's a cookie. Although I've probably written the same code at least ten times, I can't for the life of me remember it. So you know what I do? That's right, I Google it.

Let's repeat that nice and slow. If you don't know the answer to a programming problem... You. Google. It.

Right after writing that question I decided to test myself, and I was able to find a reasonable solution in about 5 seconds. However, I don't depend on an IDE for autocomplete (Sublime Text for the win), so writing the correct import statements was the work of a 3-second Google and ample Ctrl+F-ing. Here's my final solution after about a minute:

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.io.IOException;

public class Test {
public static void main(String[] args) throws IOException {
FileInputStream fstream = new FileInputStream(args[0]);
BufferedReader br = new BufferedReader(new InputStreamReader(fstream));
String line;
int i = 0;
while((line = br.readLine()) != null) {
if ((i % 2) == 0) {
System.out.println(line);
}
++i;
}
br.close();
}
}
This breaks a few Java best practices, and also I'm rusty. So sue me.

The point is, knowing how to Google is important. I'm constantly amazed by the disparity in Googling skill that I've seen between "good" programmers during my internship (and let me tell you, some of these guys were wizards) and intro-level computer science students while I was a TA.

In lab one day, a hapless student popped a question much like the one above. I didn't know the answer either (what, you expect me to tattoo BufferedReader onto the back of my hand?) so I told him to Google it. Then I watched. And I was mortified. It was a wonder the student managed to find anything, and eventually I had to help him along. "Read a file Java," I said. Four words. And what do you know, the first hit was a winner.

In another part of the world, I watched expert Googling on a daily basis. Unless you're one of the venerable greybeards of a large tech company (and they are unfortunately an endangered species), you spend your working hours in a near-constant state of searching: trying to hunt the root cause of a bug here, learning a new framework there. Over the summer this Firefox plugin became my best friend. I chewed through Stack Overflow and system documentation for breakfast, lunch, and occasionally dinner.

From these experiences, I've come to believe wholeheartedly that there's a strong relationship between being a good "searcher" and being a good programmer. I also believe that both can be taught.

Causation

How to Think
This might be a bit harder to teach, but it's perhaps the most important of all.

In many ways, progressing through a computer science curriculum is like doing the 100 meter hurdles. You start off running, and then you come to a hurdle, and you either jump over it or trip and fall and have to make an appointment to see your advisor. Then you repeat until you reach the finish line and get a piece of paper that companies value for no good reason.

In other words, the whole experience is very canned. You learn how to write a for-loop, and then you apply your newfound knowledge, and then you move on to the while-loop. Maybe you learn about databases and then do an assignment or two setting up a database of animals and drawing entity-relationship diagrams. Maybe you take an AI class and read a paper about the Turing Test and watch a few boring videos on genetic algorithms, then try to answer ten homework questions before Friday. Knowledge, knowledge, knowledge, but the application is all on training wheels.

Fun fact: in a real job, your manager isn't going to ask you ten questions or give you sample code. You're going to be given an abstract problem and unrealistic expectations, and then set free on your rickety bike with no training wheels. Good luck.

This past semester, I've noticed that I do remarkably little thinking in college. Sure, there's thinking involved in trudging through assignments and digesting textbook material, but it's not the active creative kind I've learned to associate with the workplace. I've also noticed the same trend in other students, and if the only programming they do is for school, then they are disastrously unprepared for applying their knowledge after college ends. Or, as this amazing article about learning math says:

"Teachers can inadvertently set their students up for failure as those students blunder in illusions of competence."
But, how to teach someone to think? Here I don't mean thinking so much as I mean applying programming concepts to real-world problems, which does indeed require a level of creative thought several orders of magnitude above anything you see in school. Is this something that can even be taught?

A colleague of mine now working towards his PhD is pondering the very same questions. He believes, as the article about math above does, that what's missing is a fundamental understanding of programming concepts at the very beginning. We finish canned assignments and get passing grades and so are led to believe we "understand" programming, but when we see something novel we are unable to apply what we've learned, most likely because we don't have enough practice. It's a 10,000 hour sort of thing.

Which brings me to...

The Secret Ingredient
Okay, so if you become a programming virtuoso through years of grueling practice, are you willing to invest all that time and effort? Most freshmen probably wouldn't. I myself chose computer science because I wanted to learn how to make video games, and was very nonplussed by discrete math in my first semester. The thought of rote programming would turn me off very quickly, but our goal is to make computer science more inviting to the masses.

So here's what I tell people when they ask me how to become a better programmer (for some odd and undeserved reason I've been getting that question a lot recently): think of something you really want to make, and make it.

This is the secret ingredient. A DIY project outside of school or work, on your own free time.

The first trick to this exercise is to disregard everything you think you know or don't know. Set unrealistic goals. Make the next Facebook. The first hurdle you'll have to overcome is turning this lofty dream into something tangible. What language will you use? Will you need a database? What will your product look like? What colors will it be in? Decisions, decisions. All requiring a measure of knowledge and creative thought to answer.

Chances are you won't know what you need to know right away. Maybe you've never set up a web server before (if your project happens to require one), so you're going to need to learn how. That's right...Google to the rescue.

Learning something as "out there" as setting up your own web server when you have absolutely no web experience has the advantage of honing one of life's great skills: autodidacticism (no, I didn't know that word off the top of my head, Google to the rescue again). Some of us are gifted with the amazing ability to be self-taught, but for others it's like being thrown into the lion's cage with a juicy steak on the first day of the new zoo job. However, like anything else, it's a skill that can be improved over time. Yes, you might get mauled the first few times. But soon you'll be slinging steaks with the best of them.

Whatever your project, I would only hope that you use a VCS to manage it and write ample tests. Just a suggestion.

As you can see, working on a DIY project can make up for any shortcomings of being a computer science major and then some. But there's one more benefit: it keeps you interested. Tired of writing the Fibonacci sequence? Can't think of why you'd want to know how to print out every other line of a text file? Having second thoughts about programming as a career? Make a website. Or a sweet app. Or a game to amaze your friends.

Do what you've always wanted to do. You'll be surprised how much you learn, not only about programming, but about yourself.

Original Post - http://willyg302.github.io/blog/#!/post/2014-11-07-four-things-computer-science-should-teach

If you think your Facebook feed has a lot of video now, just wait.

"In five years, most of [Facebook] will be video," CEO Mark Zuckerberg said Thursday during the company's first community town hall, in which he took questions from the public on a range of topics.

FEATURED RESOURCE

Presented by Scribe Software
10 Best Practices for Integrating Data
Data integration is often underestimated and poorly implemented, taking time and resources. Yet it
LEARN MORE
He was responding to a question about whether the growing number of photos uploaded to Facebook is putting a drag on its infrastructure. But Facebook's data centers have it covered, he said. The real challenge is improving the infrastructure to allow for more rich media like video in people's feeds.

Zuckerberg took questions from a group of users who were invited to its headquarters in Menlo Park, California, and people also submitted questions online.

One of the most popular online question was why Facebook forced users to download its Messenger app for mobile.

The 30-year-old acknowledged not everyone was thrilled with the change.

"Asking everyone in our community to install another app is a big ask," he said. But Facebook thought it could provide a better, faster messaging product if it split it off from its own app.

"We really believe this is a better experience," Zuckerberg said.

One user in the audience asked him if Facebook is losing its charm or becoming boring.

The question of Facebook losing its "cool" gets raised from time to time, Zuckerberg said, but "my goal was never to make Facebook cool," he said. Instead, he wants it to be a helpful service that just works.

Another asked why he always seems wear the same t-shirts and hoodies. Zuckerberg said he wants to spend as much time as possible on things that matter, like how to build products, even if it means thinking less about what he wears.

"Steve Jobs had the same approach," he said.

Original Article - http://www.itworld.com/article/2844410/facebook-will-be-mostly-video-in-5-years-zuckerberg-says.html

Give them laptop but I wouldn't want them to miss the good childhood days.

Learning how to code is seen today as key to building a successful life. Barack Obama, Michael Bloomberg, and even Enrique Iglesias have all urged people to study coding. This goes against the grain of history. Why, in our modern day, are we expecting people to speak like computers? Shouldn't computers learn to speak our language instead?

In the '80s and the '90s, engineers built products so people wouldn't need to 'speak computer.' Apple and Microsoft made their fortunes by making computing accessible to everyone, through a visual, intuitive user experience. When they were founded, people had to master the command line to use computers. The Apple II and Windows replaced this command line with a graphical user interface, allowing computer use to expand from a few specialists to nearly everyone. This is a general trend in technology: everything becomes easier over time, and as it does, more people use it.

Programming hasn't followed this path yet. BASIC, one of the very first programming languages, celebrated its 50th birthday last May, and yet, modern programming languages still reflect this archetypal approach. The way people program today is by typing highly structured text -- the code -- in a text editor. We have to write things so that it's easy for the computer to parse them, instead of being easy for us to read them. True, a lot has been done to make the coding process faster, through better learning tools (forums like Stack Overflow), and code-sharing (the Open Source movement). However, and in spite of these efforts, you still need to be trained as an engineer to build software.

50 years from now, I can't imagine people programming as we do today. It just can't be. The future I imagine is a world in which programming is self-explanatory, where people talk to computers to build software. To get there, programming tools should first use our language. For instance, to turn a button red, we shouldn't have to write code. We should just be able point to the button and select a shade of red. Instead of talking about concepts the computer cares about (like variables and servers), programming tools should talk about things the programmer cares about (an image or a cloth order).

This could change everything in the way we live. With more accessible programming, farmers could program robots to intelligently tend crops based on local soil conditions; teachers could build software to adjust their teaching based on what happened the day before around the school; chefs could set up systems to buy fresh fish from the nearby market in real time as people place orders. However, that won't happen if farmers, teachers or chefs have to learn code to do it, because it's not their expertise. Instead, programming tools should be able to speak like a chef, to a chef. Software tools should be created by their users, because their users know their needs better than anyone else. A software engineer will never know cooking as well as a chef does. Teaching people how to code to turn them into engineers is not the solution.

Revolutionizing programming is one of the most amazing opportunities of our time. There isn't a field where computers haven't had an impact yet, and it's only the beginning. This is fantastic, as it allows doing more with less. But how do we want to get there? There are two ways. One way is to rely on engineers to build the products that will transform everything else. We would -- in fact, we've already started to -- turn engineers into an elite class that runs our world. Major tech companies would control how we live. People that do not know how to program will at some point become redundant. Think about taxi drivers. Do you think they will still be needed after Google's driverless cars go mainstream? We're talking about a lot of people: the United States has 3.5 million truck drivers and 300,000 taxi drivers. Globally, hundreds of millions will eventually lose their jobs.

The other option is to give the power of creation to everyone. Instead of being consumers of technology, people will produce it. This will unleash tremendous economic potential, as the number of people able to build new products and companies will skyrocket. It will create new jobs and opportunities for more people. It will also be extraordinarily empowering to enable people to build their own solutions to their own problems. That's why making programming accessible to everyone is an incredible opportunity. As technologists, it's our responsibility to make this happen soon. I hope to see others join us to make this a reality.

Original Article - http://www.huffingtonpost.com/emmanuel-straschnov/you-shouldnt-have-to-lear_b_6111914.html?utm_hp_ref=technology&ir=Technology

I think it's nice. Do you plan on making a mobile app?

Teens, tweens and kids are often referred to as “digital natives.” Having grown up with the Internet, smartphones and tablets, they’re often extraordinarily adept at interacting with digital technology. But Mitch Resnick, who spoke at TEDxBeaconStreet in November, is skeptical of this descriptor. Sure, young people can text and chat and play games, he says, “but that doesn’t really make you fluent.”

Mitch Resnick: Let's teach kids to code Mitch Resnick: Let's teach kids to code Fluency, Resnick proposes in today’s talk, comes not through interacting with new technologies, but through creating them. The former is like reading, while the latter is like writing. He means this figuratively — that creating new technologies, like writing a book, requires creative expression — but also literally: to make new computer programs, you actually must write the code.

The point isn’t to create a generation of programmers, Resnick argues. Rather, it’s that coding is a gateway to broader learning. “When you learn to read, you can then read to learn. And it’s the same thing with coding: If you learn to code, you can code to learn,” he says. Learning to code means learning how to think creatively, reason systematically and work collaboratively. And these skills are applicable to any profession — as well as to expressing yourself in your personal life, too.

In his talk, Resnick describes Scratch, the programming software that he and a research group at MIT Media Lab developed to allow people to easily create and share their own interactive games and animations. Below, find 10 more places you can learn to code, incorporating Resnick’s suggestions and our own.

At Codecademy, you can take lessons on writing simple commands in JavaScript, HTML and CSS, Python and Ruby. (See this New York Times piece from last March, on Codecademy and other code-teaching sites, for a sense of the landscape.)
.
One of many programs geared toward females who want to code, Girl Develop It is an international nonprofit that provides mentorship and instruction. “We are committed to making sure women of all ages, races, education levels, income, and upbringing can build confidence in their skill set to develop web and mobile applications,” their website reads. “By teaching women around the world from diverse backgrounds to learn software development, we can help women improve their careers and confidence in their everyday lives.”
.
Stanford University’s Udacity is one of many sites that make college courses—including Introduction to Computer Science—available online for free. (See our post on free online courses for more ideas.)
.
If college courses seem a little slow, consider Code Racer, a “multi-player live coding game.” Newbies can learn to build a website using HTML and CSS, while the more experienced can test their adeptness at coding.
.
The Computer Clubhouse, which Resnick co-founded, works to “help young people from low-income communities learn to express themselves creatively with new technologies,” as he describes. According to Clubhouse estimates, more than 25,000 kids work with mentors through the program every year.
.
Through CoderDojo’s volunteer-led sessions, young people can learn to code, go on tours of tech companies and hear guest speakers. (Know how to code? You can set up your own CoderDojo!)
.
Code School offers online courses in a wide range of programming languages, design and web tools.
.
Similarly, Treehouse (the parent site of Code Racer) provides online video courses and exercises to help you learn technology skills.
.
Girls Who Code, geared specifically toward 13- to 17-year-old girls, pairs instruction and mentorship to “educate, inspire and equip” students to pursue their engineering and tech dreams. “Today, just 3.6% of Fortune 500 companies are led by women, and less than 10% of venture capital-backed companies have female founders. Yet females use the internet 17% more than their male counterparts,” the website notes.
.
Through workshops for young girls of color, Black Girls Code aims to help address the “dearth of African-American women in science, technology, engineering and math professions,” founder Kimberly Bryant writes, and build “a new generation of coders, coders who will become builders of technological innovation and of their own futures.”
While we’re at it: bonus! General Assembly offers a variety of coding courses at their campuses across the globe. Additionally, their free online platform, Dash, teaches HTML, CSS and Javascript through fun projects on a simple interface that is accessible from your web browser.

Original Post - http://blog.ted.com/2013/01/29/10-places-where-anyone-can-learn-to-code/

The following are just a collection of some useful shortcuts and tools I've found in Python over the years. Hopefully you find them helpful.

Swapping Variables

x = 6
y = 5

x, y = y, x

print x
>>> 5
print y
>>> 6
Inline if Statement

print "Hello" if True else "World"
>>> Hello
Concatenations

The last one is a pretty cool way to combine objects of two different types.

nfc = ["Packers", "49ers"]
afc = ["Ravens", "Patriots"]
print nfc + afc
>>> ['Packers', '49ers', 'Ravens', 'Patriots']

print str(1) + " world"
>>> 1 world

print `1` + " world"
>>> 1 world

print 1, "world"
>>> 1 world
print nfc, 1
>>> ['Packers', '49ers'] 1
Number Tricks

#Floor Division (rounds down)
print 5.0//2
>>> 2

#2 raised to the 5th power
print 2**5
>> 32
Be careful with division and floating point numbers.

print .3/.1
>>> 2.9999999999999996

print .3//.1
>>> 2.0
Numerical Comparison

This is a pretty cool shortcut that I haven't seen in too many languages.

x = 2

if 3 > x > 1:
print x
>>> 2

if 1 < x > 0:
print x
>>> 2
Iterate Through Two Lists at the Same Time

nfc = ["Packers", "49ers"]
afc = ["Ravens", "Patriots"]

for teama, teamb in zip(nfc, afc):
print teama + " vs. " + teamb

>>> Packers vs. Ravens
>>> 49ers vs. Patriots
Iterate Through List With an Index

teams = ["Packers", "49ers", "Ravens", "Patriots"]
for index, team in enumerate(teams):
print index, team

>>> 0 Packers
>>> 1 49ers
>>> 2 Ravens
>>> 3 Patriots
List Comprehension

With a list comprehension we can turn this:

numbers = [1,2,3,4,5,6]
even = []
for number in numbers:
if number%2 == 0:
even.append(number)
Into this:

numbers = [1,2,3,4,5,6]
even = [number for number in numbers if number%2 == 0]
Pretty sweet huh?

Dictionary Comprehension

Similar to the list comprehension we can also do a dictionary comprehension like this:

teams = ["Packers", "49ers", "Ravens", "Patriots"]
print {key: value for value, key in enumerate(teams)}
>>> {'49ers': 1, 'Ravens': 2, 'Patriots': 3, 'Packers': 0}
Initialize List Values

items = [0]*3
print items
>>> [0,0,0]
Converting a List to a String

teams = ["Packers", "49ers", "Ravens", "Patriots"]
print ", ".join(teams)
>>> 'Packers, 49ers, Ravens, Patriots'
Get Item From Dictionary

I'll admit that try/except code doesn't look the prettiest. Here's a simple way to fix that with dictionaries. This will try to find the key in the dictionary and if it can't be found it will set the variable to the second parameter.

Instead of:

data = {'user': 1, 'name': 'Max', 'three': 4}
try:
is_admin = data['admin']
except KeyError:
is_admin = False
Do this:

data = {'user': 1, 'name': 'Max', 'three': 4}
is_admin = data.get('admin', False)
Taking a Subset of a List

Sometimes you only want to run code over a portion of a list. Here are a few ways you can get the subset of a list.

x = [1,2,3,4,5,6]

#First 3
print x[:3]
>>> [1,2,3]

#Middle 4
print x[1:5]
>>> [2,3,4,5]

#Last 3
print x[-3:]
>>> [4,5,6]

#Odd numbers
print x[::2]
>>> [1,3,5]

#Even numbers
print x[1::2]
>>> [2,4,6]
FizzBuzz in 60 Characters

A while back Jeff Atwood popularized a simple programming exercise called FizzBuzz. Here is the excerpt on the problem:

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
Here's a short, fun way to solve the problem.

for x in range(1,101):print"Fizz"[x%3*4:]+"Buzz"[x%5*4:]or x
Collections

In addition to python's built in datatypes they also include a few extra for special use cases in the collections module. I find the Counter to be quite useful on occasion. Some of you may even find it useful if you're participating in this year's Facebook HackerCup.

from collections import Counter

print Counter("hello"
>>> Counter({'l': 2, 'h': 1, 'e': 1, 'o': 1})
Itertools

Along with the collections library python also has a library called itertools which has really cool efficient solutions to problems. One is finding all combinations. This will tell us all the different ways the teams can play each other.

from itertools import combinations

teams = ["Packers", "49ers", "Ravens", "Patriots"]
for game in combinations(teams, 2):
print game

>>> ('Packers', '49ers')
>>> ('Packers', 'Ravens')
>>> ('Packers', 'Patriots')
>>> ('49ers', 'Ravens')
>>> ('49ers', 'Patriots')
>>> ('Ravens', 'Patriots')
False == True

This is more of a fun one than a useful technique. In python True and False are basically just global variables. Thus:

False = True
if False:
print "Hello"
else:
print "World"

>>> Hello
If you've got any other cool tips/tricks leave them in the comments below. Thanks for reading!

Original Post - http://www.maxburstein.com/blog/python-shortcuts-for-the-python-beginner/

A lot of us want certain apps and software but we don't have enough money to purchase it, so I'm trying to figure out a way to get what we need and want at a cheap and free price.

DGr8GOD:
Hi David Smith, thanks 4 D's link. It is very good. Good work. But, let me ask, what wud I b able to do if sign up to create page? Thanks

I don't understand your question. Can u please clarify?

The past two years I’ve had the chance to interact with over 500+ developers on this African continent - I’ve attended Developer events across the continent from Kampala, Lagos, Accra, Nairobi and interacted with developers from Cairo, Kinshasa, Jo’bug, Maputo, Dar-es-salaam, Monrovia, Kigali, Juba, Lusaka and Dakar.

At events like GTUG’s, DevFests, Barcamps, Where camps, Google G Days, Hackathons, RHoK’s, University Talks, code-labs - name it, I’ve been there. So I feel confident to write about my findings. I have put thesedevelopers in 3 different categories with characteristics relating them to previous African dictators. From my findings i can say these are the kinds of developers you will find in Africa.

Developer Charles Taylor
Just like Charles Taylor , these developer’s strongest weapons are rape and torture of existing code. They willalways exploit existing tools to construct something to meet the client’s needs.

Developers in this category are the guys who have only mastered CMS’s (Content management systems) the likes of Joomla, WordPress, Drupal, concrete5 etc. These guys can edit and patch up the source code, they can tweak these platforms to what they really need them to do. They only edit, re-arrange, pull out, make few changes and have what they need. They can’t build a module from scratch or re-write one.

Just like Charle Taylor’s wealth, some thing i noticed also is that these guys are rich in work to showcase - sites, blogs, templates etc they have and can show you what they have done. At Tech events these guys have very little to contribute as they can’t really write code and work in groups. Something I’ve also noticed with these guys is that a few are moving to RAD platforms like cakephp, codeigniter. Most of the developers in this category write code in or understand PHP.

Developer Robert Mugabe
Just like Robert Mugabe these developers mostly have gone to school and passed through some British/colonial education (programming lessons). They have Microsoft certifications or have done some IT/CS schooling. They use any Microsoft tools given to them and they only know those tools. Developers under this category mostly run on Windows machines and code in Java and .Net Technologies. These guys have some good programming knowledge but purely base everything they do on what they learnt in school.

I’ve noticed that most of the people who win prizes at Tech/Coding events fall under this category. The thing I hate about these guys is that they are rigid, don’t try new things, stick to Java and .Net technologies and are not willing to learn new technologies. They are not into FOSS technologies and know nothing about **nix platforms. They don’t contribute to Open source initiatives so you won’t see them own github or Google code accounts, they have all their code on their laptops. The thing I like with these guys is that they get things done.

Developer Idi Amin
Just like Idi Amin a primary 3 drop-out who didn’t go to school but rose through the ranks in the army to reach far as to rule a Country, these developers mostly have learnt whatever skills they got on their own. I’ve noticed that they mostly own Linux / Mac Machines. They code in languages like Perl, Erlang, Bash, Python, PHP, C++ etc.

Just like Amin who declared him self President for life, these developers at Code events don’t like to be told what to do or how to do things, they just want to be left alone to figure out everything on their own. Something I’ve noticed with these guys is that they understand the OOP principles and can build modules from first principles (bottom - up). They also have another problem, they have nothing to showcase as most of their code / projects are incomplete.

On top of development these guys know basic Sys Admin on Linux platforms and for development, they go as far as understanding coding styles, re-factoring, code readability, Test driven development, Scrum, Modeling etc. These guys also care about nitty gritty things like memory and CPU usage etc.

Developers under this category also get things done but need lots of patience on your side, you need to take them delicately as they are easily offended. These are the kind of guys you will find sited in isolation at back of i-hub Nairobi , next to Pete’s coffee with dark screens and looking very busy like they are changing the world, yet they may just be installing a **nix patch.

The biggest problem with developers in this category is that they don’t have girlfriends and live all their lives on their laptops (including weekends) and some in the Bar.

All in all, I think most of the developers in Africa fall under the developer Charles Taylor and developer Robert Mugabe, that’s why the two most common languages used here in Africa are PHP and Java.

Original Post - http://thedatafugee..com/2012/11/the-3-types-of-developers-you-will-find.html

Reading books is great, reading other people’s code is great but no other technique is more efficient for those trying to learn a new programming language than actually writing code.

That said, I’m making a suggestion here: copy Unix.

How? Gimme a hint.

Suppose you’re learning Python, you should try to build a copy of the cat program with it or try to implement tree, for example.

Unix programs are often small and focused on doing something unique and doing it very well (read more about the concept), which is also ideal for learning to program. Just pick up a single problem and solve it in the best way possible.

Chris Wanstrath has an example of it from long ago.

Reproducing these tiny programs in your language of choice has the amazing benefit of helping you learn about the classes and functions of that language.

Have this for an example:

#!/usr/bin/env ruby

# Reproducing cat in Ruby would be as simple as this:

ARGV.each do |file|
puts File.read file
end
Although virtually doable with any programming language, this technique works even better if you’re learning a scripting language like Ruby or Python. Or even JavaScript with Node.js.

As developers we always need to learn things. I think small habits like this can make a difference.

Original Post - http://sgtpeppers.me/copy-unix/

So, you’ve been working with Java since the very beginning? Remember the days when it was called “Oak”, when OO was still a hot topic, when C++ folks thought that Java had no chance, when Applets were still a thing?

I bet that you didn’t know at least half of the following things. Let’s start this week with some great surprises about the inner workings of Java.

1. There is no such thing as a checked exception
That’s right! The JVM doesn’t know any such thing, only the Java language does.

Today, everyone agrees that checked exceptions were a mistake. As Bruce Eckel said on his closing keynote at GeeCON, Prague, no other language after Java has engaged in using checked exceptions, and even Java 8 does no longer embrace them in the new Streams API (which can actually be a bit of a pain, when your lambdas use IO or JDBC).

Do you want proof that the JVM doesn’t know such a thing? Try the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Test {

// No throws clause here
public static void main(String[] args) {
doThrow(new SQLException());
}

static void doThrow(Exception e) {
Test.<RuntimeException> doThrow0(e);
}

@SuppressWarnings("unchecked"
static <E extends Exception>
void doThrow0(Exception e) throws E {
throw (E) e;
}
}
Not only does this compile, this also actually throws the SQLException, you don’t even need Lombok’s @SneakyThrows for that.

More details about the above can be found in this article here, or here, on Stack Overflow.

2. You can have method overloads differing only in return types
That doesn’t compile, right?

1
2
3
4
class Test {
Object x() { return "abc"; }
String x() { return "123"; }
}
Right. The Java language doesn’t allow for two methods to be “override-equivalent” within the same class, regardless of their potentially differing throws clauses or return types.

But wait a second. Check out the Javadoc of Class.getMethod(String, Class...). It reads:

Note that there may be more than one matching method in a class because while the Java language forbids a class to declare multiple methods with the same signature but different return types, the Java virtual machine does not. This increased flexibility in the virtual machine can be used to implement various language features. For example, covariant returns can be implemented with bridge methods; the bridge method and the method being overridden would have the same signature but different return types.

Wow, yes that makes sense. In fact, that’s pretty much what happens when you write the following:

1
2
3
4
5
6
7
8
abstract class Parent<T> {
abstract T x();
}

class Child extends Parent<String> {
@Override
String x() { return "abc"; }
}
Check out the generated byte code in Child:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Method descriptor #15 ()Ljava/lang/String;
// Stack: 1, Locals: 1
java.lang.String x();
0 ldc <String "abc"> [16]
2 areturn
Line numbers:
[pc: 0, line: 7]
Local variable table:
[pc: 0, pc: 3] local: this index: 0 type: Child

// Method descriptor #18 ()Ljava/lang/Object;
// Stack: 1, Locals: 1
bridge synthetic java.lang.Object x();
0 aload_0 [this]
1 invokevirtual Child.x() : java.lang.String [19]
4 areturn
Line numbers:
[pc: 0, line: 1]
So, T is really just Object in byte code. That’s well understood.

The synthetic bridge method is actually generated by the compiler because the return type of the Parent.x() signature may be expected to Object at certain call sites. Adding generics without such bridge methods would not have been possible in a binary compatible way. So, changing the JVM to allow for this feature was the lesser pain (which also allows covariant overriding as a side-effect…) Clever, huh?

Are you into language specifics and internals? Then find some more very interesting details here.

3. All of these are two-dimensional arrays!
1
2
3
4
5
class Test {
int[][] a() { return new int[0][]; }
int[] b() [] { return new int[0][]; }
int c() [][] { return new int[0][]; }
}
Yes, it’s true. Even if your mental parser might not immediately understand the return type of the above methods, they are all the same! Similar to the following piece of code:

1
2
3
4
5
class Test {
int[][] a = {{}};
int[] b[] = {{}};
int c[][] = {{}};
}
You think that’s crazy? Imagine using JSR-308 / Java 8 type annotations on the above. The number of syntactic possibilities explodes!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Target(ElementType.TYPE_USE)
@interface Crazy {}

class Test {
@Crazy int[][] a1 = {{}};
int @Crazy [][] a2 = {{}};
int[] @Crazy [] a3 = {{}};

@Crazy int[] b1[] = {{}};
int @Crazy [] b2[] = {{}};
int[] b3 @Crazy [] = {{}};

@Crazy int c1[][] = {{}};
int c2 @Crazy [][] = {{}};
int c3[] @Crazy [] = {{}};
}
Type annotations. A device whose mystery is only exceeded by its power

4. You don’t get the conditional expression
So, you thought you knew it all when it comes to using the conditional expression? Let me tell you, you didn’t. Most of you will think that the below two snippets are equivalent:

1
Object o1 = true ? new Integer(1) : new Double(2.0);
… the same as this?

1
2
3
4
5
6
Object o2;

if (true)
o2 = new Integer(1);
else
o2 = new Double(2.0);
Nope. Let’s run a quick test

1
2
System.out.println(o1);
System.out.println(o2);
This programme will print:

1.0
1
Yep! The conditional operator will implement numeric type promotion, if “needed”, with a very very very strong set of quotation marks on that “needed”. Because, would you expect this programme to throw a NullPointerException?

1
2
3
4
5
6
Integer i = new Integer(1);
if (i.equals(1))
i = null;
Double d = new Double(2.0);
Object o = true ? i : d; // NullPointerException!
System.out.println(o);
More information about the above can be found here.

5. You also don’t get the compound assignment operator
Quirky enough? Let’s consider the following two pieces of code:

1
2
i += j;
i = i + j;
Intuitively, they should be equivalent, right? But guess what. They aren’t! The JLS specifies:

A compound assignment expression of the form E1 op= E2 is equivalent to E1 = (T)((E1) op (E2)), where T is the type of E1, except that E1 is evaluated only once.

This is so beautiful, I would like to cite Peter Lawrey‘s answer to this Stack Overflow question:

A good example of this casting is using *= or /=

byte b = 10;
b *= 5.7;
System.out.println(b); // prints 57
or

byte b = 100;
b /= 2.5;
System.out.println(b); // prints 40
or

char ch = '0';
ch *= 1.1;
System.out.println(ch); // prints '4'
or

char ch = 'A';
ch *= 1.5;
System.out.println(ch); // prints 'a'
Now, how incredibly useful is that? I’m going to cast/multiply chars right there in my application. Because, you know…

6. Random integers
Now, this is more of a puzzler. Don’t read the solution yet. See if you can find this one out yourself. When I run the following programme:

1
2
3
for (int i = 0; i < 10; i++) {
System.out.println((Integer) i);
}
… then “sometimes”, I get the following output:

92
221
45
48
236
183
39
193
33
84
How is that even possible??

.

.

.

.

.

. spoiler… solution ahead…

.

.

.

.

.

OK, the solution is here and has to do with overriding the JDK’s Integer cache via reflection, and then using auto-boxing and auto-unboxing. Don’t do this at home! Or in other words, let’s think about it this way,

7. GOTO
This is one of my favourite. Java has GOTO! Type it…

1
int goto = 1;
This will result in:

Test.java:44: error: <identifier> expected
int goto = 1;
^
This is because goto is an unused keyword, just in case…

But that’s not the exciting part. The exciting part is that you can actually implement goto with break, continue and labelled blocks:

Jumping forward

1
2
3
4
5
label: {
// do stuff
if (check) break label;
// do more stuff
}
In bytecode:

2 iload_1 [check]
3 ifeq 6 // Jumping forward
6 ..
Jumping backward

1
2
3
4
5
6
label: do {
// do stuff
if (check) continue label;
// do more stuff
break label;
} while(true);
In bytecode:

2 iload_1 [check]
3 ifeq 9
6 goto 2 // Jumping backward
9 ..
8. Java has type aliases
In other languages (e.g. Ceylon), we can define type aliases very easily:

1
interface People => Set<Person>;
A People type constructed in such a way can then be used interchangably with Set<Person>:

1
2
3
People? p1 = null;
Set<Person>? p2 = p1;
People? p3 = p2;
In Java, we can’t define type aliases at a top level. But we can do so for the scope of a class, or a method. Let’s consider that we’re unhappy with the namings of Integer, Long etc, we want shorter names: I and L. Easy:

1
2
3
4
5
6
7
8
class Test<I extends Integer> {
<L extends Long> void x(I i, L l) {
System.out.println(
i.intValue() + ", " +
l.longValue()
);
}
}
In the above programme, Integer is “aliased” to I for the scope of the Test class, whereas Long is “aliased” to L for the scope of the x() method. We can then call the above method like this:

1
new Test().x(1, 2L);
This technique is of course not to be taken seriously. In this case, Integer and Long are both final types, which means that the types I and L are effectively aliases (almost. assignment-compatibility only goes one way). If we had used non-final types (e.g. Object), then we’d be really using ordinary generics.

Enough of these silly tricks. Now for something truly remarkable!

9. Some type relationships are undecidable!
OK, this will now get really funky, so take a cup of coffee and concentrate. Consider the following two types:

1
2
3
4
5
// A helper type. You could also just use List
interface Type<T> {}

class C implements Type<Type<? super C>> {}
class D<P> implements Type<Type<? super D<<P>>>> {}
Now, what do the types C and D even mean?

They are somewhat recursive, in a similar (yet subtly different) way that java.lang.Enum is recursive. Consider:

1
public abstract class Enum<E extends Enum<E>> { ... }
With the above specification, an actual enum implementation is just mere syntactic sugar:

1
2
3
4
5
// This
enum MyEnum {}

// Is really just sugar for this
class MyEnum extends Enum<MyEnum> { ... }
With this in mind, let’s get back to our two types. Does the following compile?

1
2
3
4
class Test {
Type<? super C> c = new C();
Type<? super D<Byte>> d = new D<Byte>();
}
Hard question, and Ross Tate has an answer to it. The question is in fact undecidable:

Is C a subtype of Type<? super C>?

Step 0) C <?: Type<? super C>
Step 1) Type<Type<? super C>> <?: Type (inheritance)
Step 2) C (checking wildcard ? super C)
Step . . . (cycle forever)
And then:

Is D a subtype of Type<? super D<Byte>>?

Step 0) D<Byte> <?: Type<? super C<Byte>>
Step 1) Type<Type<? super D<<Byte>>>> <?: Type<? super D<Byte>>
Step 2) D<Byte> <?: Type<? super D<<Byte>>>
Step 3) List<List<? super C<C>>> <?: List<? super C<C>>
Step 4) D<<Byte>> <?: Type<? super D<<Byte>>>
Step . . . (expand forever)
Try compiling the above in your Eclipse, it’ll crash! (don’t worry. I’ve filed a bug)

Let this sink in…

Some type relationships in Java are undecidable!

If you’re interested in more details about this peculiar Java quirk, read Ross Tate’s paper “Taming Wildcards in Java’s Type System” (co-authored with Alan Leung and Sorin Lerner), or also our own musings on correlating subtype polymorphism with generic polymorphism

10. Type intersections
Java has a very peculiar feature called type intersections. You can declare a (generic) type that is in fact the intersection of two types. For instance:

1
2
class Test<T extends Serializable & Cloneable> {
}
The generic type parameter T that you’re binding to instances of the class Test must implement both Serializable and Cloneable. For instance, String is not a possible bound, but Date is:

1
2
3
4
5
// Doesn't compile
Test<String> s = null;

// Compiles
Test<Date> d = null;
This feature has seen reuse in Java 8, where you can now cast types to ad-hoc type intersections. How is this useful? Almost not at all, but if you want to coerce a lambda expression into such a type, there’s no other way. Let’s assume you have this crazy type constraint on your method:

1
<T extends Runnable & Serializable> void execute(T t) {}
You want a Runnable that is also Serializable just in case you’d like to execute it somewhere else and send it over the wire. Lambdas and serialisation are a bit of a quirk.

Lambdas can be serialised:

You can serialize a lambda expression if its target type and its captured arguments are serializable

But even if that’s true, they do not automatically implement the Serializable marker interface. To coerce them to that type, you must cast. But when you cast only to Serializable…

1
execute((Serializable) (() -> {}));
… then the lambda will no longer be Runnable.

Egh…

So…

Cast it to both types:

1
execute((Runnable & Serializable) (() -> {}));
Conclusion
I usually say this only about SQL, but it’s about time to conclude an article with the following:

Java is a device whose mystery is only exceeded by its power

Original Post - http://blog.jooq.org/2014/11/03/10-things-you-didnt-know-about-java/

‘It is advisable for African programmers to adopt the motive of Miami Heat in order to survive, thrive and leave a legacy similar to Lebron James, Dwayne Wade or Chris Bosh.’ – Michael A. Aboagye ( Technology/Business Journalist)

Forthnight ago, I alighted on a previous article authored by Raindolf Owusu, founder of Oasis Websoft in Accra, Ghana. He is one of the few programmers advocating for open source software in Ghana and beyond.

However in his piece, he stressed on certain factors which indirectly bar mammoth programmers from reaching the zenith or carving a niche in the technology world.

He argued that not knowing the importance of investment in project, competing against colleagues, striving to know a lot in order to be regarded as a Jack of all trades, and other worrying issues won’t aid Africa’s development in the technology world.

Below is a summary of Raindolf’s article themed as ‘Agony of an African Programmer.’

Agonies of an African Programmer: Part 2

” Working as an independent mobile, web and software developer in Africa can be a trying experience. Africa for so long has being recognized by the world as an agricultural continent and for the past decade, many software developers ( African Code Kings ) are working tirelessly to prove that we are also a technological nation by building great websites , mobile apps and softwares that aims to solve our problems on the ground. This does not come at a cheap cost. I have listed below a few of the agonies myself and most developers go through as African Code Kings.

Investment

Most developers set up a tech start-up in search for investors to fund their projects. In Africa, most people do not understand the Silicon Valley style of Angel investment and funding. Investors in Africa perceive technology as selling tomatoes in the market. When they fund a start-up, they are looking for the short term profit. For strong developers who do not need this kind of funding, they work their ass out trying to fund their personal projects. They end up taking up so many odd web dev jobs that will in turn slow down their personal projects / innovations.

Jack of all trades and master of nothing.

An African developer tries to play all the roles in a company from being the CEO to the company’s publicist. Instead of focusing on one thing and mastering the art, He spends his time mastering all the aspects of a company. It is sometimes good but it comes with its own banes.

Awards and Competitions.

It is great to participate in code competitions and hackerthons to test your coding skills, but it is a different ball game if you want to build kick-ass technology to solve real life African problems and make money along the way.”

Hence, I have decided to employ the chemistry of Miami Heat as an example to follow in order to resolve issues disturbing majority of African programmers.

The reason why I decided to use Miami Heat chemistry as an illustration is mainly based on recent achievements. Out of the few thriving NBA teams, Miami Heat can boast of three players – Eddie House, Udonis Haslem and Dwayne Wade – each with a championship ring. A championship ring is not earned easily so you could imagine how efficient is the ‘Heatles Chemistry’ crafted by Erik Spoelstra.

We certainly reminisce how the ‘Trust Theorem’ benefited the entire team during previous seasons. The flawless chemistry emulated by Eddie House, Wade and his co. against Oklahoma City on the 30th of January is indeed a required ingredient in the genes of African programmers.

In other words, when the going gets tough, turn to one another for help.

It is virtually difficult to nod disapprovingly at the fact that the entire Miami Heat team is not one of the finest basketball teams in the states. Lebron James and co. are purposely known for strategic play on home or away court. Teamwork is the hallmark of Dwayne Wade and his talented play mates. You can’t deny such fact and begrudge them. They deserve it.

Here in Africa, comparing the characters of Miami Heat to our programmers is a complete different story. Although Africa harbor hordes of uniquely talented ‘coders’ , yet are we to see them thrive beyond local communities.

Their inability to thrive ( not all programmers) is a clear reason why the majority ought, if they desire to carve a niche, adopt the ‘Heatles Chemistry’ .

‘Heatles Chemistry’ is a coined word of mine. In other words, I invented the word due to the almost flawless chemistry between Lebron, Bosh, and Wade in their hey-days. Of course, it is hardly for NBA lovers to forget how the combination between Mike Miller, Dwayne Wade, Lebron James and Eddie House saved the day for the entire team against Oklahoma City on the 30th of January. So I believe if our fellow programmers adopt some positive motives of this team, we are certain to witness moderate improvement in the immediate future.

The Relevancy of Investment

‘An Investment in knowledge pays the best interest.’- Benjamin Franklin

Investment is often regarded by most of us as a way of granting necessary funds to a project or sowing a seed into a startup to aid its development. However, Benjamin Franklin’s insight in terms of investment is a far cry from the conventional definition of investment.

The above quote by Benjamin shows that research knowledge is another major form of investment which is likely to produce considerable results.

Prior to previous successful championship, the management team knew they could cause a ‘positive threat’ if certain players are fielded within the team. The management knew they needed a three-point specialist and one who is prepared to do rigorous job of rebounding, setting picks, and feeding the basketball to the ‘‘Big 3.’’ And because the Heat were willing to go ahead of the pack, the likes of Udonis Haslem and lithunian center Zydanu were purchased at reasonable price.

Programmers in Africa could relate to the above illustration if they are indeed certain to make a mark in their career. The same worthwhile results could be achieved if ‘knowledge’ investment is done thoroughly before the ball is set rolling. Knowledge investment is achingly painful but the output is certain to be profitable if research is done properly. We can’t afford to miss opportunities which leads to wider doors and grant us rare chance to compete with others developers based in Silicon Valley. Let us invest in knowledge for the sake of Africa’s development.

Jack Of All Trades, Master Of None

‘It is difficult to find a team focusing and believing in the same vision of other startups.’ – Raindolf Owusu (founder of Oasis Websoft).

We can’t deny the fact that Africa has intelligent ‘coders’ who are ready to deliver when called upon to resolve any thinkable problems worrying humanity and the environment we live in ( except apathy, depression and other emotional problems).

However, it is disturbing to hear many programmers struggling to be regarded as Jack of all trades. Have in mind that the moment you begin to wrestle for ‘Jack of all trades’ title, no one is likely to tout you as an expert or an authority on linux , windows, Java, python, Coffee Script, Php, Oracle, artificial intelligence and other languages.

At Miami Heat, each and every player is known for specific skills. Dwayne Wade on a good day could launch three – pointers with ease because he practice consistently.

Relating the above analogy to programmers in Africa is a different story altogether. Programmers prefer to learn diverse programming languages without managing to master at least one or two languages.

Here in Ghana, when it comes to open source software, Raindolf Owusu is virtually on the lips of every Ghanaian within the technology industry. His vision to raise awareness concerning open source usage in local communities is very noticeable. Also, we can talk of other geeks like Alfred Rowe ( of encodev labs) known purposely for building event apps.

The best way to resolve ‘Jack of all trades’ canker is to focus on one or two languages, master it and strive to learn about other languages but not into details.

Competition

‘Stop competing with others. Start competing with yourself.’ – Anonymous

The sooner developers or programmers acknowledges the relevance of not competing against each other, the better.

What would have happened if Dwayne Wade compete against Lebron James; Udonis Haslem strives to better than Zydrunas Ilgauskas or Eddie’s main focus is to win more championship ring than Dwayne Wade? Perhaps, the ‘heatles Chemistry’ we enjoyed previously and recently won’t have materialized.

The best example to illustrate a picture of depending on one’s skill and each other rather than competing or showing a desire to eclipse each other could be related to the game between Miami Heat and Oklahoma City on the 30th January.

Trailing 103 -102 against Oklahoma City, Wade and his men needed to produce a magical performance to triumph over their rivals.

As determined as they were, the mentality of Mike Miller to corporate with Eddie and James to widen the gap proved worthwhile eventually.

The same goes to developers in Africa. Although competition possess a force which could ignite creativity, excessive competition destroys one’s focus and intent to carve a niche or leave a legacy similar to Dennis MacAlistair Ritchie.

I firmly believe if much emphasis is be placed on self-improvement rather than focusing largely on one’s rival, significant achievements is bound to take place.

Original Post - http://www.siliconafrica.com/the-heatles-chemistry-is-required-in-the-genes-of-african-programmers/

paullo240:
[color=#990000][/color] MY NAME IS PAUL, AM STILL A STUDENT, AND I HAVE A DREAM TO BECOME TO BECOME ONE OF THE GREAT INTERNET ENTERPRENUERS.. I DONT CHEW WORDS BUT WILL SHOE YOU DETAILS. I WANT PEOPLE WHO ARE COMPUTER ORIENTED, VOLUNTEER, COMMITED AND SHARE THE SAME DREAM AS MINE TO JOIN HANDS WITH ME IN CREATING A WONDERFUL APP THAT WILL GROW AND LATER BECOME GLOBAL, COS I BELIEVE THAT THIS FACEBOOK, WHATAPP, ALIEXPRESS WERE JOINTLY CREATED PEOPLE. SO IF YOU ARE INTERESTED DROP UR NAME, NUMBER, UR KNOWLEGDE IN COMPUTER. YOU CAN HOOK UP WITH ME AT 08084740706 OR EMAIL ME AT pauladuaka@gmail.com THANKS.

What is your app or idea? Or will you like to brainstorm?

mathefaro:
To be more specific, can a graduate of mathematics actually make it big time in the IT industry (with lots of professional certifications in the IT sector though)?
I need this info to advice a student who needs counseling

What is your definition of success? Is success determined by money? If so, then a Comp Sci degree is NOT needed. Is success determined by getting degrees and writing papers? Then a Comp Sci degree IS needed. Is success determined by peace of mind and having a family? Than a Comp Sci degree is NOT needed. Let me give u a quick answer. There are many Bachelors, Masters & PHD. holders of Comp Sci n IT but do u know the funniest thing? Majority of them end up working for people who don't have a single degree in Computer Science and IT. Isn't that funny? Most billionaires around the world never went to college, there are even more millionaires that are high school dropouts. At the end of the day, I think it is about chance, determination, luck and opportunities.

Here is amass a list of programming books that are freely available on the Internet. The books can be about a particular programming language or about computers in general. Does anyone have anymore? More resources are on the way. Please keep updated for those that are interesting in jumping into programming.

Link - https://free-programming-books.zeef.com/victor.felder

VivaLaFrans:
Iam a Computer Science student and just wanted to know where all the topics in this forum are being stored. Since it'll last forever, then where are they stored. Google?

To answer the main title, I'll say that Nairaland has the ability to become a search engine (if the workers were taken it seriously), but I doubt it if they are. Nairaland has the potential to become a rival search engine to Google, but the ogas at the top don't seem to be pushing it or let's just say innovative.

As far as where the topics are stored, more than likely in a database.

Having trouble finding tips for beginner developers who want to take their career to the next level? Justin James aims to fill this information gap with his suggestions about how to make that leap.
During an e-mail exchange with a TechRepublic member, he mentioned that blogs, articles, and magazines aimed at developers seem to fall into two categories: items for beginners ("Hello World" type tutorials) and items for experts (MSDN Magazine). It's a really good point; there's very little information out there to help a developer make the leap from beginner to intermediate. Here are 10 things you need to do to make that transition.

#1: Learn another language
It doesn't matter which language you learn, but learning another language (regardless of how many you already know) will make you a better developer. Even better is to learn one that is significantly different from what you already use on a regular basis. In other words, if you are a C# developer, learning VB.NET or Java will not help you as much as learning Ruby or Groovy.

And when I say "learn another language," I mean really learn it. Learning a language consists of three realms of knowledge: the syntax, the built-in operators and libraries, and "how to use it." The first two are easy; I think that an experienced developer can pick up enough of a language's syntax to maintain code in 30 minutes to a few hours depending upon the language. The operators and libraries are just a matter of slowly accumulating knowledge and being willing to check reference materials until you memorize what you need to know. But it's the third item -- "how to use it" -- that can only be learned over months of working with a language and that's where the real magic happens. I suggest doing a project that is well suited for that language and doing it in that language's style.

Truly learn another language, and I promise that your abilities as a developer will start to blossom.

#2: Learn advanced search techniques, tactics, and strategies
More and more, being a good developer is not just about your skill, but your skill at finding information. Simply put, modern languages and development frameworks are too large for most people to remember much of them. As a result, your ability to get work done is often dependent upon your ability to perform research. Unfortunately, knowing how to find accurate, high-quality information is more than just heading to TechRepublic for the answer or typing a few words into your search engine of choice.

"Techniques," "tactics," and "strategies" may sound like synonyms, but they are not. The techniques you need to learn are the advanced search systems of your favorite search engine; you need to learn things such as the Boolean operators, how to filter results (negative keywords, domain restrictions, etc.), what role word order plays, and more. So essentially, RTFM.

You should learn tactics such as knowing how to approach any particular search and knowing what you should you actually look for. Errors are easy -- just look for the error code -- but keyword selection on many searches is much more difficult.

With regard to strategies, you need to learn things such as what search engines to use (hint: general purpose search engines are not always the right answer), which sites to visit before going to a general purpose search engine, and even which message boards to post to for help.

#3: Help others
Teaching others is invariably one of the best ways to learn anything. It is understandable to think that you don't have much to offer because you are relatively new to the development field. That's nonsense. Remember, everything you know you learned from someone or somewhere; so try being the someone that another person learns from. Spend a few minutes a day trying to answer the questions on TechRepublic or another site as best you can. You can also learn a lot by reading other members' answers.

#4: Be patient and keep practicing
Research shows that it takes "about ten years, or ten to twenty thousand hours of deliberate practice" to become an "expert." That's a lot of time. Furthermore, becoming an expert does not always mean doing the same task for 10 years; it often means doing a wide variety of tasks within a particular domain for 10 years. It will take a lot of time and energy to become an "expert"; working as a developer for a few years is not enough. Want to become a senior developer in your early 30s? Either start your education/training sooner or be willing to do a lot of work, reading, and practicing in your spare time. I started programming in high school, and I devoted a lot of off-hours to keeping up with the industry, learning new skills, and so on. As a result, I hit the intermediate and senior level developer positions significantly earlier in my career than most of my peers, which translates to an awful lot of money over time.

#5: Leave your dogmas at the door
Time for some brutal honesty: Beginner developers probably don't know enough to state that there is One Best Way of doing something. It's fine to respect the opinion of a friend or an authority figure, but until you are more experienced, don't claim their opinions as your own. The simple fact is, if you don't know enough to figure these things out on your own, what makes you think that you know which "expert" is right? I know this sounds really harsh, but please believe me; I have met far too many budding developers who had their careers or their growth set back years because they got hung up on some foolish piece of advice or followed some "expert" who really didn't know what they were talking about. A great example of this is the abuse of object-oriented architecture. For example, many beginners read some information about OO, and suddenly the class diagrams to their simple applications look like the Eiffel Tower.

#6: Learn a few advanced ideas in-depth
Much of what goes into being an intermediate developer is having a few concepts that you are really good at working with in code. For me, it is multithreading/parallelism, regular expressions, and how to leverage dynamic languages (and the last two are fading as I get farther away from my Perl history). How did this happen? Multithreading and parallel processing came about because I read articles on it, thought it sounded interesting, and figured it out on my own; I keep writing apps that use those techniques. I had a job that used a ton of regular expressions in Perl. Also, I ended up writing my own e-commerce engine with a template processing engine and built-in database system; then I spent nearly two years working on it.

Find something that has you really hooked. It might be image manipulation or maybe database design or whatever. Even if you're an entry-level developer over all, try to become an expert in at least one area of focus. This will get you into that intermediate level quite quickly, and once there, you will be halfway to expert.

#7: Learn the basic theories underlying your field
It's one thing to write "Hello World," but it's another to understand how the words appear on the screen. By learning the "groundwork" that supports the work you do, you will become much better at it. Why? Because you will understand why things work the way they do, what might be wrong when things are broken, and so on. You will become better by learning what happens at a lower level than your work.

If you are a Web developer, read the HTTP RFC and the HTML spec. If you use a code generator, really look at the code it generates; if you use database tools, take a look at the underlying SQL it generates; and so on.

#8: Look at senior developers' code
At your job, take a look at the code the senior developers are writing and ask how and why things were done a particular way. If you can, check out open source projects as well. Even if other developers don't have the best coding habits, you'll learn a lot about how code is written. Be careful not to pick up bad habits along the way. The idea here isn't to just blindly imitate what other developers are doing; it's to get an idea of what works and what makes sense and try to imitate it.

#9: Learn good habits
Nothing marks an inexperienced coder like stupid variable names, poor indentation habits, and other signs of being sloppy. All too often, a developer learned how to program without being taught the less interesting details such as code formatting -- and it shows. Even though learning these things will not always make your code better or you a better developer, it will ensure that you are not viewed as an entry-level developer by your peers. Even if someone is a senior developer, when variables are named after their 97 cats or their functions are called "doSomething()," they look like they do not know what they are doing, and it makes their code harder to maintain in the process.

#10: Have fun
Want to be stuck on the career treadmill? Hate your job. What it takes to move up in this business is not merely dogged determination to bring home an ever growing paycheck but an actual enjoyment of your work. If you do not like your work and you are a junior developer, what makes you think that being an intermediate or senior developer will be any better? Change jobs or change careers. On the other hand, if you love the work you are doing, great! I guarantee that you can become a better developer if you keep at it.

Original Post - http://www.techrepublic.com/blog/software-engineer/10-tips-to-go-from-a-beginner-to-an-intermediate-developer/

This post is about the lessons we’ve learned building and maintaining APIs over the last three years. It starts off with some high-level thoughts, and then dives right into the detail of how and why we've made the design decisions we have, while building our second API - GoCardless Pro.

The problem with APIs

The hard thing about APIs is change. Redesign your website and your users adapt; change how timestamps are encoded in your API and all of your customers' integrations break. As a payments API provider even a single broken integration can leave thousands of people unable to pay.

As a fast-moving startup we're particularly poorly positioned to get things right first time. We're wired to constantly iterate our products: ship early then tweak, adjust, and improve every day. As a startup the uncertainty goes even deeper: we're always learning more about our customers and making course corrections to our business.

Building dependable APIs in this environment is hard.

Different types of change

The most important lesson we've learned is to think about structural changes differently to functionality changes.

Structural changes affect the way the API works, rather than what it does. They include changes to the URL structure, pagination, errors, payload encoding, and levels of abstraction offered. They are the worst kind of changes to have to make because they are typically difficult to introduce gracefully and add little to existing customers. Fortunately they're also the decisions you have the most chance of getting right first time - an API's structure isn't tied to constantly-evolving business needs. It just takes time and effort, and is discussed in "Getting your structure right" below.

Functionality changes affect what the API does. They include adding new endpoints and attributes or changing the behaviour of existing ones, and they're necessary as a business changes. Fortunately they can almost always be introduced incrementally, without breaking backwards compatibility.

Getting your structure right

In our first API we made some structural mistakes. None of them are serious issues, but they have led to an API that is difficult to extend due to its quirks. For instance, the pagination scheme relies on limits and offsets, which causes performance issues. We also had frequent discussions about whether resources should be nested in URLs, which resulted in inconsistencies.

Before we started work on GoCardless Pro, we spent a lot of time laying the structural foundations. Thinking about the structure of GoCardless Pro was helpful for several reasons:

we were forced to think upfront about issues that would affect us down-the-line, such as versioning, rate-limiting, and pagination;
when implementing the API, we could focus on its functionality, rather than debating the virtues of PUT vs PATCH;
consistency across the API came for free, as we’re not making ad-hoc structural decisions.
We adopted JSON API as the basis for our framework and put together a document detailing our HTTP API design principles. The decisions made came from three years of experience running and maintaining a payments API, as well as from examining similar efforts by other companies.

Amongst other things, our framework includes:

Versioning. API versions should be represented as dates, and submitted as headers. This promotes incremental improvement to the API and discourages rewrites. As versions are only present in incoming requests, WebHooks should not contain serialised resources - instead, provide an id to the resource that changed and let the client request the appropriate version.
Pagination. Pagination is enabled for all endpoints that may respond with multiple records. Cursors are used rather than the typical limit/offset approach to prevent missing or duplicated records when viewing growing collections, and to avoid the database performance penalties associated with large offsets.
URL structure. Never nest resources in URLs - it enforces relationships that could change, and makes clients harder to write. Use filtering instead (e.g. /payments?subscription=xyz rather than /subscriptions/xyz/payments)
This list is by no means exhaustive - for more examples, check out our full HTTP API design document on GitHub.

When starting work on a new API we encourage you to build your own document rather than just using ours (though feel free to use ours as a template). The exercise of writing it is extremely helpful in itself, and many of these decisions are a question of preference rather than "right or wrong".

Functionality changes

You can’t ever break integrations, but you have to keep improving your API. No product is right first time - if you can’t apply what you learn after your API is launched you’ll stagnate.

Many functionality changes can be made without breaking backwards compatibility, but occasionally breaking changes are necessary.

To keep improving our API whilst supporting existing integrations we:

Use betas extensively to get early feedback from developers who are comfortable with changes to our API. All new endpoints on the GoCardless Pro API go through a public beta.
Version all breaking changes and continue to support historic versions. By only ever introducing backwards-incompatible changes behind a new API version, we avoid breaking existing integrations. As we keep track of the API version that each customer uses, we can explain exactly what changes they'll need to make to take advantage of improvements we've made.
Release the minimum API possible. Where we have a choice between taking an API decision and waiting, we choose to wait. This is an unusual mentality in a startup, but when building an API, defaulting to inaction is probably the right approach. As we’re constantly learning, decisions made later are decisions made better.
Introduce “change management” to slow things down. This is not our typical approach - “change management” is a term that makes many of us shudder! But changes to public APIs need be introduced carefully, so however uneasy it makes us, putting speed bumps in place can be a good idea. At GoCardless, all public API changes need to be agreed on by at least three senior engineers.
Stop thinking like a startup

To sum up: when building an API, you need to throw most advice about building products at startups out the window.

APIs are inflexible so the advice founded on change being easy doesn’t apply. You still need to constantly improve your product, but it pays to do work up-front, to make changes slowly and cautiously, and to get as much as possible right from the start.

Original Post - https://gocardless.com/blog/lessons-learned-building-apis/

It’s simpler, terser, and more powerful than JS. Its macro system lets you treat code as data and write functions that write code for you. Jisp’s extremely simple syntax protects against common JS pitfalls, and it abstracts away some legacy details, helping avoid errors and keep your code short.

See Why Jisp for a gist of why you should use it.

The jisp compiler is itself written in jisp. See the sourcecode on GitHub. See the issues section for known problems, upcoming enhancements, and ideas how to contribute to the language.

You can improve this documentation by sending pull requests to the gh-pages branch of the project repository.

Link - http://jisp.io/

This is my article series to teach people how to build iPhone and iPad applications who have no programming experience.

My focus is to explain things in simple, plain English and get people started making their own apps. Rather than trying to teach everything I learned about Computer Science in University or every last aspect of programming, I’ll distill it into what you need. My approach will be to slowly introduce concepts as you need them, rather than trying to equip you with everything up front only to overwhelm you!

It’s really not that far fetched as long as you have the desire to learn and the persistence to keep at it and get better!

Programming can be self-taught and yes, you can start your own career in software development even if you don’t have a formal background. It’s probably the single greatest thing I love about my field; that merit is based on your achievements and hard work rather than seniority or experience (as in the case of a surgeon for example).

Original Article - http://codewithchris.com/how-to-make-iphone-apps-with-no-programming-experience/

naijatechworld:


1. Well it cuts data cost by removing images and information that is not needed
2. It directs you quickly to the app site so that one doesn't have to waste time
3. It loads up faster and it gives you a broader range of jobs in Africa. Many Nigerian job search engines only stick to Nigeria or other countries in West Africa at most.

About how much data cost? How fast and efficient is it compared to other job search sites? Africa is a big continent, not a country. How long will it take u 2 have all the job vacancies in Africa online, when many people in Africa don't have the internet?

naijatechworld:
I've removed the popup that use to show up on my website so now you can access http://getjob.comxa.com/ without any disturbance.

I just visited this site and it is pretty neat and simple. I like the job search engine but what makes it different than other job search engines like Jobberman and etc? Why should users use your search engine, when they can use Jobberman or something else? What makes your search engine special? Or different?