At my university it's common to call acyclic, connected graph a tree. We distinguish between rooted and unrooted trees. For example, minimal spanning tree doesn't really have to be rooted, it just has no cycles.
Could you illustrate? I can find plenty of examples of mirroring/reversing a tree (below the root node) but none that really invert it. I haven't even found a definition of what inverting a tree means (aside from some academic papers I haven't been able to read yet), despite quite a bit of googling.
We're a small, passionate, agile team of developers. We work remotely via Campfire, Jira, Confluence, and Hangout. We meet regularly during the year to enjoy some time together and stay connected to the rest of the Decisiv management team and the service and sales groups. We're flexible, autonomous, and strongly committed to delivering a valuable service with a great user experience. We work hard but sustain a healthy work/life balance.
Your experience should show some or all these:
Work with Ruby and Rails
Huge success in API (RESTful) development
Test or behavior-driven development and CI
Object design, data modeling and software architecture skills
Understanding of business requirements and acceptance criteria
Selection of new technologies with creativity and due diligence
It’s great if your experience also demonstrates:
Deep SQL or no-SQL skills
Integrating with external systems
Developing significant libraries, algorithms or adapters
Managing complexity in large applications
Leadership of project, team or process
We'd love to see your Github account, code samples, or anything that shows your work. If such are unavailable, we can give you a short coding exercise. If you provide an example design document or README (or even an email) demonstrating thought and communication that's helpful too. So drop us a line and tell us about yourself!
Candidates must be located in the United States and be able to work legally in the United States. Absolutely no companies - only individual developers who want to join a team and are looking for long term employment.
To apply send resume/CV and cover letter to firstname.lastname@example.org
I think the only people who would really have been offended by it are those who hadn't listen to it :) It's the same sort of banter you hear at clubs, conferences, and other podcasts, except that I'm not very smart and James is (or was... ugh, still having a hard time believing he's gone).
I just listened to it and it is full of good quotes, my favourite: "Discussions without good definitions are doomed to fail." (about the upcoming NoSQL dabate). I feel that's still ringing true in that sector.
This is the list I typically see given to newbies (on freenode ##OpenGL, and /r/opengl) wanting to learn modern OpenGL.
1. Arcsynthesis's gltut (http://www.arcsynthesis.org/gltut/) is good and reasonably thorough. He explains things well but not always in the order you'd like him to. At the end you will probably know enough to be able to figure out the rest on your own as you need.
2. http://open.gl/ is good but somewhat short. It also goes in depth into creating/initializing a context with various APIS (SDL, SFML, GLFW, ...). More of a good starting point than a complete guide.
3. http://ogldev.atspace.co.uk/ has a lot of good tutorials on how to do more advanced techniques, as well as many beginner level tutorials. I've never gone through them so I can't speak to their quality, but I've heard good things.
See /r/opengl and freenode's ##OpenGL channel for more. Both those places are fairly newbie friendly (/r/opengl moreso than ##OpenGL, but as long as you actually know your language of choice they're nice), so feel free to ask questions.
I remember this link being posted recently and since I have some interest in looking into this area as well, it stuck with me (and a browser tab ;)
While it's not a tutorial or anything, the article addresses the question "where do I start?" and mentions (not only in the title) "modern OpenGL" specifically.
I worked at a place where 50% of our time was supposed to be refactoring/boy scouting/cleanup work. The codebase was so bad and delivery so painful that management endorsed it. But the pressure to deliver never let up and so that policy is now a running joke.
I don't get much out of simply reading code. I have to get my hands in there and see how it works.
I load it into a repl and play around. See how changing little things effects tests. I add print statements to give a narrative. I draw diagrams of the code flow, especially startup, shutdown and sometimes error/exception handling.