If you are making the repositories public, GitHub is the way to go. You only have to pay if the repositories are private. It gives you the ability for people to send pull requests for changes (which you can choose to accept), issue tracking, etc. The pull request system is really nice, because you ultimately have control of what gets pulled into your project, but anyone can pull it down. It's pretty much the standard hosting, and works across all platforms.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
I've been in the industry nearly 15 years now. I think not having a degree has only come up maybe one or two times. Sure didn't stop me from getting recruited by Microsoft.
What I would focus on is a couple of things:
- Expand your horizon - learn the basics (See Michael Feathers Self-Education and the Craftsman talk from SCNA 2009). Then learn things like Functional Programming, Dynamic Typing and other languages.
- Do other things - Make programming a hobby and a career. Start an open source project. Contribute to others. Scratch itches that bug you, but do them with software
- Read, Read, Read - Find books on software engineering. Reverse Engineering of Viruses. Design Patterns. Project Management. And go outside - books on Business topics are especially good, because you get to understand the tradeoff that often gets made.
- Practice, Practice, Practice - Do Katas. Create projects. Explore ideas. Do things like Ludum Dare and hackathons. Build an iPhone app, then build an Android version.
I'm not trying to knock a college education - if you want it for the education. If you want it just for the advancement, the things above are going to have a much bigger impact on your career and your ability to find employment in many cases.
Joey Asher also wrote "Even a Geek Can Speak" - a book I give to just about anyone starting out giving presentations. This book looks just as awesome - can't wait to pick it up!
Link to Original Source
This was my thought as well. The analysis was wrong ("They have weapons! He has an RPG! Several AK-47s!") and that's a mistake which shows the need for better analysis. I mean, the guy did appear to have an RPG to me before they opened fire, but it didn't look like he was pointing it at any of them.
Far worse was the decision not to evacuate the kids. I mean, the soldiers on the ground had a much better view of what was going on, and to deny that was a travesty. And the cover-up makes it all that much worse.
In general, I see this as bad intelligence leading to a unfortunate call by soldiers looking to keep themselves safe. That doesn't excuse what happened by the commanders by any means. But I can't image being in that pilot's seat. Or the ground soldier when they made the call not to evacuate the kids.
Link to Original Source
Link to Original Source
Besides, if you really wanted to block them, wouldn't one just block the Googlebot? Or nofollow the entire site? Or robots.txt the entire site?
What they really want is to be in the top of the search results without having to have the stuff out there. You can't have it both ways.
The point is that
Of course, they could just have him not have it some of the times, or put it in the motorcade when he isn't, etc, etc. I'd imagine that you could use some of the attacks mentioned in the article to foil the above scenario even without the president having a BB. For example, if you know which phones are SS phones, and suddenly 5 or 6 are *way* away from the "motorcade" you might suspect something is up.
For the US, I'd imagine it not being too big of an issue - but the point with him being in foreign countries is pretty important.
(Notice: I'm the reviewer)
iDang it. iI'm iSorry. iI iGot iToo iCaught iUp iIn iIing iEverything.
The first thing you'll need to do is head over to the Apple Developers Site and register for an account. You can then download the iPhone API. Note that while the API download and simulator are free — deploying to a real iPhone or iTouch is not, even if it is your own. To do that you have to apply to the iPhone Developer Program which is $99. For the book, you'll be fine with just the simulator with the exception of any accelerometer application, since the simulator doesn't have that feature.
With that out of the way, I was quite impressed with the book. Although I've done quite a bit of development in the past, I haven't worked with Objective-C before, and was a little concerned if I would be in over my head. If you are in that position, don't fear — the authors do a great job of walking you through, and you'll find yourself working with it in no time.
The first chapters introduce you to the basics of the iPhone and development, starting with the canonical "Hello, World" application. The book walks you through how to get and install Xcode and the iPhone API. It then introduces you to Interface Builder, the partner-in-crime to Xcode. Even in the first chapter, the authors show their attention to detail, explaining common issues you might run into (like trying to Build and Run while your iPhone or iTouch is plugged in to your Mac).
Chapter 3 introduces the Model-View-Controller paradigm, a pattern that is probably one of the most misunderstood patterns in UI development. They give you enough information to be familiar with the terms you'll be using, and they very much mean it when they tell you not to worry if you aren't understanding something — they always loop back around to make sure you understand it.
Chapter 4 was a long chapter for me, but introduces some important concepts around user interaction and controls. By the end, you have an interface which has a variety of controls which interact with each other. As with the other chapters, the authors introduce tips and tricks to make things easier (for example, Option->Cmd->Up Arrow to switch from the header to implementation file in Xcode).
Chapter 5 covers autorotation and basic animations, including linking in the Core Graphics Framework. I especially like how the authors gave three different ways of making your app auto-rotation aware, describing the benefits and drawbacks of each. Chapter 6 follows this up by introducing multi-view interfaces, something very necessary as you get into more complex iPhone development.
Chapters 7-9 describe various methods to presenting information to users, including toolbars, table views, hierarchical navigation and hierarchical lists. However, it isn't all drag-n-drop, the authors get into some good (and sometimes deep) conversations about what you are doing. For example, in Chapter 8, they talk about issues with NSDictionary and how to create deep mutable copies.
Chapters 10-13 are the last of the "fundamentals" — application settings, basic data management, custom drawing using Quartz and Open GL, and taking inputs (including gestures and multi-touch). As someone who spends most of his time as far away from graphics libraries as possible, I was quite impressed with the basics that were introduced and what someone like me could get up and running.
Finally we get into the fun. Chapter 14 introduces Core Location, allowing to figure out where in the world you are. The book goes through a discussion about the various ways to get location information, and drawbacks of each. (Helpful tip: no matter which method, if you are polling every second, you'll drain the battery pretty quickly). For the simulator-only users, this is when things start to become tricky. Chapter 14 does work, though you aren't prompted for access to Core Location.
Chapter 15, however, is useless without an actual phone, even though it's perhaps the most fun. In this chapter, the book goes through the accelerometer and all the interesting things you can do with it. There's even a small discussion on the physics (but just enough!). Both apps you create (Shake and Break and the Marble game) are quite fun for someone just starting out with all of this. It's a shame Apple couldn't figure out a way yet to include the accelerometer in the simulator.
Chapter 16 covers using the iPhone camera and Photo Library. It's short, but it shows the power of the simple interfaces Apple provides. In just 9 pages you'll be capturing images right from the iPhone.
The final two chapters I thought were quite fitting — Localization and Follow-Ups. In the localization chapter, the book covers extracting strings out to resource files and using locale to read them in. Having a day job which ships our software in 12 different languages, I know first-hand how difficult localization can be to get right, so I was glad to see this chapter. The final chapter is just a wrap-up of resources you can reach out to for help and information.
All in all I was very surprised and pleased with the book. I've had the fortune of reading many technical books, and few do a great job of walking someone through the basics without making them feel like a dolt. It felt like every time I was stuck or unsure there was a tip, hint or paragraph which explained what was going on.
The main drawback to me is the fee to deploy apps to your own phone. This wasn't something I ran into doing either J2ME or Windows Mobile apps in the past, and it is a shame that to even work on your own phone you have to pay a fee. However, since the fee does give you the ability to submit apps to the App Store, then I guess it's a consolation. I'd rather Apple lock deployments to one iPhone (or iTouch) for the truly casual people who just want to do interesting things on their own phone.
In summary, I give this book five $1000 Rubys for making a clean, concise, easy-to-read and follow introduction to iPhone development. Great job guys!"
Basically what I was thinking as well. I did it while I was on a conference call, and was disappointed to see that this was all there was to it. I figured at the very least that it was just a first-level and the real puzzle would be on the site. Oh well.
And the article is not by Jim Shore, who wrote the linked article at the bottom of the summary. TYPO TYPO TYPO