Are the Dart 1.x books still relevant, now that Dart 2 is released? Dart 2 documentation only points to a migration guide. I am trying to learn Dart and was wondering if I should buy one of the Dart 1.x based books or should wait for the publication of Dart 2 based books
Dart 1 books will be about 80% correct. The problem will be sussing out the 20%.
The type system is VERY different in ways that can be surprising.
I'd start with https://dart.dev/guides
The language is moving pretty quickly. No book you get will be as updated as you want!
Related
This question already has an answer here:
Are Dart 1.x books still relevant?
(1 answer)
Closed 3 years ago.
I read on many places that Dart 2 is not completely backward compatible with Dart. I found a list of books that are for Dart 1.x
https://dart.dev/resources/books
Can someone with Dart 1 and Dart 2 experience tell me if this books are relevant for learning Dart 2, can I use them or I should wait for release of some Dart 2 book.
I am not sure that this is the relevant place for this type of question, but I did't found anything more suiting in the Stack Exchange network.
Yes sure it is relevant. For the language instance creation keywords like new and const have become optional to help declutter the code. They’ve made a number of small changes and done some cleanup on the dart core libraries. Nothing huge to worry about :)
Given the information at both the Polymer and Dart conferences in the last week, there is no information mentioned about the intersection of polymer and dart called PolymerDart at neither of them (except a passing wave, 2 word statement in 1 slide at the dart conference after watching the conference a second time). Given the last commit for it has been in July, only adding some tests for PolymerDart I am leaning towards yes.
I have been looking into a variety of other sources and it seems that while Polymer and Dart are separately going to continue on their own things respectively, there is no support any longer for the union. Polymer is focused entirely on PolymerJs and web component standards, where as Dart is pushing deep into AngularDart and its associated architecture. It seems that after looking deeper into it, the Googlers who were managing this union was in fact a side project, which does not actually have set resources, so there isnt a defined team in place for PolymerDart compatibility.
Given this information and the fact that Google regularly releases a lot of things, some thrive and some die all the time. They let the community determine it, and is shown over and over again throughout their many projects.
Has anyone else obtained any information related deeper into this? All my signs are pointing to it being dead. That said, maybe i should be looking to migrate my team from this and more towards angulardart.
I did as best as I could to only make note of facts and not opinions of any sort, as my opinions are not on trial, the continued development in a fast paced technology where stagnant codebases imply a dead-in-the-water technology.
After watching the talks it seems to me that the focus is more on making angular2 dart, the angular 2 dart components and the dev compiler more stable and robust.
It's eventually not dead at the moment, but priorities might have shifted.
Thus, you might want to give https://pub.dartlang.org/packages/polymerize a try.
I have a bright idea that I want to develop and thus want to learn web programming. I have searched high and low only to be confused by all the JS'es and the frameworks and all the never ending pros and cons.
I have recently come across Google Dart and its somewhat reassuring to know that all I will ever need for web application development is possible and there in one place. First question if I just learned Dart would this previous statement that I don't need to learn anything else be true?
Secondly, how should one go about learning Dart? Can I learn directly, if not what prerequisites should I know first to get started on Dart?
First of all you should know that all the information that interests you exists on the main site: Dart: Structured web apps.
This site include the following information:
Get started:
Get Dart
Get Tutorials
Technical Overview
Docs:
Programmer’s Guide
Dart API Reference
Language Specification
Dart Cookbook
Dart: Up and Running
Books on Dart
Articles
Frequently Asked Questions (FAQ)
Tools:
Dart Editor
Pub Package Manager
More tools for Dart
Resources:
Dart Code Samples
Dart Synonym: Translations from Dart
Try Dart online
Dart Presentations
Dartisans: The Dart show and podcast
Dart Tips: Short Video Tutorials
Dart Bug and Feature request
Community:
Contact the Dart Project
Contributor's Guide
Community Resources
Within these resources, you can find a lot of useful information for getting started with Dart.
Also, they contains a lot of links to other external sources of information.
Several years ago, I started learning php. Twice. And twice did I fail, because I just read theory and did not code php itself.
If you want to learn Dart, just start developing. Think of an idea you would like to implement and start developing it. Every few lines of code you will stumble and have no clue how to solve something, and therefore you will have to read theory, ask on stackoverflow - but will always have in mind, what your precise goal is.
Time will pass, you will have implemented 2-3 ideas of yours and will have covered a great deal of Dart.
Learning by doing.
If you don't even know HTML, I suggest starting with the Dart Tutorials.
I am trying to help some people getting started programming on rails identify which version that advice found on web pages corresponds to, and am seeking advice and/or guides on how to do it so they don't have to rely on me and/or waste time trying outdated advice.
Narrative: I am helping some people get up to speed on rails development, and their stock response to running into problems is searching google for advice. They're using 2.3.5 and thinking of moving to 3. The problem they're running into is that there's a lot of advice out there specific to older rails versions (2.2 for example being popular) that isn't identified.
I can usually figure out when the pages are old pretty easily, but they can't (yet.) It seems like random web page authors don't identify which version they're using when they're using the current version, and not all pages are dated.
This seems to be a general problem that will get worse -- current unadorned advice is usually 2.3.5 and older unadorned advice is 2.2.x at this point, but people are moving / will be moving to version 3 over the next while and newbies will be stuck looking at a bunch of deprecated/incompatible 2.3.x advice without realizing which version it is.
Any advice / pointers / telltales?
Check out API Dock. It has an excellent, annotated, and more importantly, versioned documentation of the rails API.
When I started with Rails 2.x last year, I got some books that were talking on Rails 1.x
There were things that changed from 1.x to 2.x, such as the way scaffolding works or that a framework like streamlined stopped from existence. On the other hand, there were some concepts and points that stayed valid from Rails 1.x to 2.x For example, most tutorials and documents start on talking about the model layer, how easy it is to use ActiveRecord and how you have REST for dealing with basic CRUD operations.
In general, I think with such an active community, it's actually one of the strong point of rails that you get so many shifts in innovation so fast. Actually, it is one of the strong points of the open-source community.
I began reading the book "Code Complete" 2nd edition, but stopped reading when I noticed most of the solutions were easily solvable in Ruby with Ruby idioms. Is there a similar book for Ruby?
Here's the version that I started reading:
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
Pick that book back up and start where you left off. As someone who read the first edition and these days writes Ruby for a living, I can confidently say that the lessons of Code Complete are universal. The wisdom in that book about good code construction - quality naming, decoupling, how to structure a function, etc. - will stand any programmer in good stead. I still refer to my dog-eared first edition regularly.
As far as books on practices which pertain more specifically to Ruby: first, every programmer should have a copy of "The Ruby Way, 2nd Edition", by Hal Fulton, on his or her desk. Second, while I haven't read it yet, I have heard good things about "Ruby Best Practices".
For such an old programming language (well, maybe not "Lisp" old, but Ruby is older than Java, after all) and a community that fanatic about code quality, style and beauty, the Ruby book market is surprisingly light on "higher level" books.
There are several reasons for this: a lot of Rubyists are already seasoned Smalltalk or Lisp programmers when they pick up Ruby, so they don't need those books. And Ruby and Smalltalk are similar enough that you can just read a Smalltalk book instead. (For example, you can pretty much read Stéphane Ducasse's list of free Smalltalk books from top to bottom.) The same goes for Perl.
Until very recently, the best higher level Ruby book was basically Smalltalk Best Practice Patterns by Kent Beck. (There is a newer version of this book, called Implementation Patterns which uses Java instead of Smalltalk. However, since Kent's Java style is very Smalltalk-ish, it is essentially SBPP, 2nd Ed.) However, since then, several higher level books have been released or are in the works:
Design Patterns in Ruby by Russ Olsen,
Ruby Best Practices by Gregory T. Brown,
Refactoring: Ruby Edition by Jay Fields, Shane Harvie, Martin Fowler and Kent Beck (a re-interpretation of Fowler's book in Ruby) and
Rein Henrichs is (or at least was, as of last year) working on Ruby Best Practice Patterns.
As stated in the comment above, I'm not sure what I should recommend.
However you might take a look at the Pragmatic Series with books like Practices of an Agile Developer or The Pragmatic Programmer if you dont know them yet. At least they drop the C parts, but unless you go for the explicit Ruby-stuff they will use languages like C# for demonstration.