Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: Re:Apple will eventually drop its computer line? (Score 2, Insightful) 764

by davebaum (#33178616) Attached to: Microsoft Losing Big To Apple On Campus

You might want to look at Apple's Q3 results: http://www.apple.com/pr/library/2010/07/20results.html

I don't think Apple breaks down revenue by product type, but they sold 3.47M macs, 8.4M iPhones, 9.41M iPods during the quarter. My guess is that the macs are their highest margin products, but even if margins were the same across the board the price point of a mac is much higher than the other products. Because of this, it is likely that macs are generating at least a third of Apple's hardware revenue and profits. They aren't about to walk away from a business that is generating billions of dollars per year in profit.

Comment: Re:I don't think so... (Score 3, Interesting) 237

by davebaum (#29773823) Attached to: Author Encourages Users to Pirate His Book

Back when I wrote a book, three different publishers sent me contracts and the one from Apress was the most author-friendly by far. The royalty rates were higher, and the terms limiting the exclusive rights were written with authors in mind. All in all I found it to be an equitable arrangement - they were taking a risk by fronting the production costs and wanted a chance at profit. I was compensated more than fairly for the work I did.

The accounting never confused me. The percentage is paid on revenue (not profit), so there isn't any "hollywood accounting". There are several different kinds of sales, each with their own price, but it all adds up.

The "reserve" is really very simple. Distributors order more books than they might need from the publisher. These count as sales. But the publisher also will allow excess inventory to be returned. If the publisher paid out all royalties in full, then at the tail end of a book's life when returns exceeded sales, they would have to ask for money back from the author. It is also difficult to gauge the ups and downs of sales/returns (lots of sales in Q4 followed by returns in Q1). The reserve is a buffer against that. A sort of minimum balance that the publisher owes you but is escrowed against possible returns. Honestly, I never found it to be a problem.

Comment: Code reviews are for more than just finding bugs (Score 1) 345

by davebaum (#28323629) Attached to: Are Code Reviews Worth It?

Yes, code reviews are nominally about finding problems with the code, but they can also be used to...

* Share knowledge. You can learn a lot of new things by looking at someone else's code. Perhaps they use a library class you aren't familiar with, or have used a language feature in an elegant way. Just as an artist will look at other artist's work as part of their growth, programmers shouldn't be working in complete isolation. And even if you are the amazing guru that knows everything, then at least your teammates will be able to benefit from your vast knowledge.

* Ensure that every line of code has been seen by at least two people. Code that has only been worked on and looked at by a single person is a liability. If they leave the company (or project or whatever) you suddenly have this huge morass of code that nobody is familiar with, and you probably only start to realize this when there's a nasty bug that needs to be quickly fixed in that code.

* Tests can help with correctness, but do not necessarily make the code maintainable. Even if your code is correct, if a question comes up in code review, then that's an indication that you need to write clearer code and/or better comments if you expect anyone else to be able to work on the code in your absence.

That being said, a bad code review is probably not worth it. Keep the amount of code being reviewed at a single time relatively small. Don't involve too many people - just one other person looking at the code will provide a lot of value at minimal cost. If you start inviting managers and "process czars", then you're on the wrong track. Review code promptly: one-on-one reviewer led discussion works well (they read your code and ask you questions as they go). Code review tools can help, especially if the programmers are in different time zones. Everyone needs to make reviews a priority - aim for 24 hour max turn-around on a review otherwise you'll find everyone always being blocked. I think letting the author pick the reviewer(s) is important. That way if someone is a complete jerk about code reviews, nobody will ever include them in the reviews and you have minimized the damage that person can cause.

Comment: Probably Verilog (Score 2, Informative) 301

by davebaum (#28160837) Attached to: VHDL or Verilog For Learning FPGAs?

VHDL and Verilog each have their strengths, which is why neither has been able to supplant the other. Perhaps in the long run System Verilog will change this (bringing much of the power of VHDL to the Verilog world), but that day hasn't arrived yet.

 

Verilog code tends to be very concise, with the language making some implicit conversions and assumptions that turn out to be correct most of the time.

 

VHDL is bigger, bulkier and more rigid. The rigidity can be annoying, but it also is good at catching errors. The language has features that allow for very elaborate testbench construction, and some powerful means for abstraction (the generate statement, multiple architectures for an entity, etc). But this power comes at a cost. The spec for the language is several times larger than for VHDL. At one point I had a Verilog quick reference that fit nicely on a single page. My equivalent quick reference for VHDL covered four pages.

 

I've gone through the "choose an HDL" process twice, and both times selected VHDL. But that was within the context of at least half the team already being fluent in VHDL, and working on a large enough (and long lived enough) codebase that we could take advantage of some of VHDL's power. I wish VHDL wasn't so cumbersome and verbose, but it was still a win overall.

 

You are in a very different situation. I'm assuming you have minimal experience with either language, and it will be new to your students as well. You're going to have plenty of other things to be worrying about (digital design, synthesis, debugging, etc). I think Verilog is a better choice for your situation. It's going to do everything you need, and not really get in your way.

 

Also, don't worry about which tool is more popular in industry. Tools change many times over a career. University classes should be about providing good theory and foundation, so pick whatever tool enables you teach those concepts most effectively.

Comment: Re:Tax breaks for the rich? (Score 2, Informative) 260

by davebaum (#28104575) Attached to: Apple Plans $1 Billion iDataCenter
According to http://www.taxfoundation.org/taxdata/show/23408.html, the rich do pay a higher percent income tax. This only covers income tax paid vs. AGI, so there can be arguments about other taxes being regressive or sources of income that aren't taxable (or aren't reported). But from the standpoint of income tax this is a reasonable metric. For 2006, the top 1% paid an average of 22.79% of their AGI in tax. The people in the top 5%-2% averaged 17.48%. The top 10%-6% paid 12.60%. One could argue that the rich should pay even more, but claiming that they pay a lower effective rate of income tax than everyone else is just not supported by the facts.

Comment: Re:Git links (Score 2, Informative) 346

by davebaum (#26399397) Attached to: Git Adoption Soaring; Are There Good Migration Strategies?
Git and Hg branches are actually quite different. In Git, a branch is just a pointer into the DAG of changesets. If you are "on" a branch and commit, the pointer is moved to the new changeset. But you can manipulate that pointer arbitrarily and point it at any changeset. These pointers are local to a single repository, although I think you can map them so that branch X in repo A corresponds to branch Y in repo B, etc.

In Mercurial, every changeset is marked as belonging to a single branch (the default is a branch named "default"). This marking happens at commit time and cannot be changed afterwards (short of creating a new commit). Typically a changeset inherits the branch name of it first parent, but you can always mark it differently before the commit. So instead of a branch being a pointer to a single changeset, it actually identifies some subset of the DAG, and when you refer to a branch you are asking Hg to figure out the tip of the DAG subset marked with that branchname. Note that since the branch name is recorded internal to the changeset, it remains the same for all clones of the repository.

Personally, I think the git mechanism is more flexible, but the hg mechanism suffices just fine for basic use cases, and leads to fewer surprises among new users.

Sentient plasmoids are a gas.

Working...