Earlier quoted context omitted.
Looks good! On my screen the text is light gray on white. Is that intentional?
Whoops! Thanks for the comment, the text should be a readable black on white (like this: https://skitch.com/kalidazad/er7an/intro-to-distributed-vers... ). Which browser were you using? (I just tried FF, Chrome, Safari) Thanks!
Got 15 minutes and want to learn Git?
171–178 of 178 posts
Re: Got 15 minutes and want to learn Git?
#172Earlier quoted context omitted.
Whoops! Thanks for the comment, the text should be a readable black on white (like this: https://skitch.com/kalidazad/er7an/intro-to-distributed-vers... ). Which browser were you using? (I just tried FF, Chrome, Safari) Thanks!
https://skitch.com/gizzlon/efrsh/screen
Thanks, really appreciate it!
Re: Got 15 minutes and want to learn Git?
#173Earlier quoted context omitted.
Rather than these n00b tutorials, I recommend reading "Pro Git" by Scott Chacon, available for free here: http://git-scm.com/book If you prefer a video, try "Getting Git" by Scott Chacon: http://vimeo.com/14629850 Coming from a Subversion & Perforce background, I was initially very confused by Git. There were two things that finally switched-on the old lightbulb for me: a) Scott's book b) Actively using Git for all o…
b) glosses over what I've found to be one of the biggest brain-twisters in git - working with remotes.
Exactly: don't tackle remotes until you've learned the fundamentals of git, otherwise you'll be stuck with a big brain twister. If you start dealing with remotes right off the bat, like I initially did, you'll find git very frustrating and weird to work with. I kept treating git like it was svn, and just didn't get it. If you learn git without remotes first, the way git handles remotes will make way more sense to you once you finally explore that functionality.
Re: Got 15 minutes and want to learn Git?
#174Earlier quoted context omitted.
You are taking it personally. >>How does "not comfortable with the command line" translate to "dumber by the day?" If people get their training using IDEs and go on to be productive using primarily IDEs, how does being uncomfortable with the command line reflect on their intelligence in any way? Because the common characteristics of such people is to heavily depend on intellisense and auto complete to do almost any t…
>>Because the common characteristics of such people is to heavily depend on intellisense and auto complete to do almost any task. Tool generated code is so common in those communities most code is generally taken care by the IDE. Import statements, exception handling, try/catch blocks, loop generation in context of previous statements. The list endless... Because that code can be easily automated... choosing not to i…
If I want to automate my programming, I use a higher level language where the boilerplate isn't required.
Re: Got 15 minutes and want to learn Git?
#175Earlier quoted context omitted.
>>Because the common characteristics of such people is to heavily depend on intellisense and auto complete to do almost any task. Tool generated code is so common in those communities most code is generally taken care by the IDE. Import statements, exception handling, try/catch blocks, loop generation in context of previous statements. The list endless... Because that code can be easily automated... choosing not to i…
If I want to automate my programming, I use a higher level language where the boilerplate isn't required.
So the examples given where these:
>> Import statements, exception handling, try/catch blocks, loop generation
What "high-level language" are you using where this stuff isn't necessary?
Re: Got 15 minutes and want to learn Git?
#176Earlier quoted context omitted.
If I want to automate my programming, I use a higher level language where the boilerplate isn't required.
So the examples given where these: >> Import statements, exception handling, try/catch blocks, loop generation What "high-level language" are you using where this stuff isn't necessary?
Ruby on Rails. It's not even that high-level, but:
1. The number of import statements in the typical code file in the typical Rails app is anywhere between 0 and 3, heavily weighted towards 0. Turns out you can metaprogram class-loading behavior in high-level languages and it just seems to work.
2. It's rare to find good places where exception handling is the best way to go in Rails, except for debugging purposes, in which case the default Rails behavior--to render the exception in a 500 if you're running in developer mode--is usually what I want.
3. Aren't try/catch blocks exception handling?
4. `.each do |e|`; `.map do |e|`. I can handle those on my own.
OK, there's serious shit you can't write in Ruby, but languages like Scala and Clojure are equally high-level, probably even more high-level, and yet have better performance and JVM integration.
Still, I understand there are legitimate reasons you'd use a language like Java, and given a language like Java, I can understand that you'd want an IDE to automate the drudgery. But I still don't like IDE's, because they're an ugly solution to a problem that doesn't need to exist. If I can concisely express what I want to do in my code to Eclipse, I should fundamentally be able to express the same idea just as concisely in the code itself.
Re: Got 15 minutes and want to learn Git?
#177Earlier quoted context omitted.
So the examples given where these: >> Import statements, exception handling, try/catch blocks, loop generation What "high-level language" are you using where this stuff isn't necessary?
Ruby on Rails. It's not even that high-level, but: 1. The number of import statements in the typical code file in the typical Rails app is anywhere between 0 and 3, heavily weighted towards 0. Turns out you can metaprogram class-loading behavior in high-level languages and it just seems to work. 2. It's rare to find good places where exception handling is the best way to go in Rails, except for debugging purposes, in…
I'm mostly ignorant of Ruby, so maybe you can help me out.
1. And how exactly do they get away with that? What if you wanted to use a class that had a name conflict with a Ruby library class? Import/require are useful for namespace resolution. It seems that not having them would just be limiting your ability to name things cleanly.
2. Well sure, exception handling shouldn't be the rule, but how often you use them isn't usually a language concern (except maybe with Java and checked exceptions). Nonetheless, when you do use them, having your IDE give you shortcuts to write the boilerplate code is a plus.
Re: Got 15 minutes and want to learn Git?
#178Earlier quoted context omitted.
Ruby on Rails. It's not even that high-level, but: 1. The number of import statements in the typical code file in the typical Rails app is anywhere between 0 and 3, heavily weighted towards 0. Turns out you can metaprogram class-loading behavior in high-level languages and it just seems to work. 2. It's rare to find good places where exception handling is the best way to go in Rails, except for debugging purposes, in…
I'm mostly ignorant of Ruby, so maybe you can help me out. 1. And how exactly do they get away with that? What if you wanted to use a class that had a name conflict with a Ruby library class? Import/require are useful for namespace resolution. It seems that not having them would just be limiting your ability to name things cleanly. 2. Well sure, exception handling shouldn't be the rule, but how often you use them isn…
> What if you wanted to use a class that had a name conflict with a Ruby library class?
I just try to avoid going around calling my classes things like "Fixnum" or "Array".
Seriously though, this kind of thing is all set up at the framework level, though you do sometimes have explicit requires for external libraries (gems) that you bring in. The Ruby standard library isn't that big, and Rails' libraries are named and namespaced intelligently and pretty much sit in the background without having to be explicitly invoked too much.
It helps that the main source of Ruby libraries is RubyGems, most RubyGems have a class or namespace named after the name of the gem, and there's a canonical source of RubyGems that doesn't allow you to use the name of gems that already exist.
> Well sure, exception handling shouldn't be the rule, but how often you use them isn't usually a language concern (except maybe with Java and checked exceptions). Nonetheless, when you do use them, having your IDE give you shortcuts to write the boilerplate code is a plus.
I guess Ruby exception handling just doesn't have much boilerplate code.