As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What pitfalls/ problems/ pains might I expect as I start building real and more complex apps with Angular ?
I am at a new job and about to recommend Angular (and Bootstrap) as the basis for building all our web apps. After nearly 1.5 years of working with backbone.js I know I don't want to use it... We have a Node + MongoDB back end and no real investment in any client side stack. One unique thing is that we have some big data - one collection that will reach 10's of gigs in size with hundreds of millions of records... I have been reading up on and playing with Angular for past two weeks or so and haven't really found anything bad about it.
There is really no pitfall :)
On to a likely less zealot explanation: AngularJS is (as far as I've been able to tell) a lot more opinionated than backbone - most processes are dead easy to perform (displaying data, processing interactions) but follow a somewhat stricter pattern to do so. Supposedly it makes angularJS harder do bend to your specific criteria than backbone, but I have found it isn't so. Also, the few shortcomings of the system are quickly disappearing, as it is evolving crazy fast.
Point in case: the routing system is one of the lesser aspects of angularJS, as it is generally not very flexible (no route inheritance, no state machine)... I started making apps using a workaround that turned out to be quite clean, explained here. However, the folks at angular-ui have come up with a solid solution and a similar solution is bound to appear in angular itself.
The animation directive was also a shortcoming (animating the appearance and disappearance of objects is tricky, as they need to exist up until the end of the animation, and that has to be managed) and has also workaround solutions, but a core animation system was introduced in the 4th of april in angular 1.1.4, here, so you see, it is rapidly evolving :)
Regarding learning curve: it has some, but nothing someone with your experience can't handle in a very short time. This series of video tutorials is the best resource i know of, as an easy way to understand the gist of most things (the documentation is good enough and getting better, but lacks applied examples in some places where it would really helped - or lacked, they may be better by now - also, the "beginners tutorial" is dreadful, I personally hate long running, step-by-step tutorials)
Hope it helps!
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm new to backbone.js and am working my way through some tutorials. I've found a couple that seem good, but there are some inconsistencies in how they implement so I'm looking for a little guidance on best practices.
Here are the tutorials I'm learning from:
http://www.jamesyu.org/2011/01/27/cloudedit-a-backbone-js-tutorial-by-example/
http://coenraets.org/blog/2011/12/backbone-js-wine-cellar-tutorial-part-1-getting-started
My questions are:
The first tut makes use of Backbone.Controller but not Backbone.Collection. The second does the opposite. Which is the best practice for the "C" in backbones spin on MVC?
The first tut defines urls in the Model, whereas the second defines it in the Collection. Which is the better practice?
The second tut makes use of Backbone.Router, while the first one does not. Which is best practice?
Alternatively if someone can suggest a better intro tutorial that follows best practices I'd be happy to learn from there. Unfortunately because of the inconsistencies between these two, I'm concerned I might be learning some bad habits out of the gate.
Thanks in advance.
Backbone.Controller was renamed to Backbone.Router last year. I guess you were reading an old tutorial.
BackboneTutorials.com is a decent tutorial for getting started.
Build a small app as you learn and you'll know what Backbone does for you.
The best way to learn Backbone is to go through the annotated source code. Each and every line is commented and explained.
Use the dev version instead of the minified version when building your app. This helps in debugging.
If you are into reading books, check out Addy Osmani's Backbone Fundamentals, a free e-book. The book is awesome, but quite verbose. You can use it as a reference.
See this question on Quora for the definitive list of resources;
Don't worry too much about what's 'V' and what's 'C' and backbone's spin on MVC.
The framework does an excellent job of separating code that interacts with the server and the code that performs the core client logic. Templating and updation of DOM Elements is left to you. It's pretty minimalistic in that sense. Backbone provides Events that make the different parts interact with each other.
this is a good question. Though, Backbone isn't taking position on how you should organize your code.
So, the real answer is: it depends.
It depends on the need of your application and how you're used to program.
If you want an overview of some best practice, I'd refer you to the Backbone Boilerplate project: https://github.com/tbranyen/backbone-boilerplate
This project is pretty solid, and really helped me out when starting.
Then, to answer your question (this may feel opiniated, and it is indeed):
1: Backbone is mostly an MV* framework (Model-View-Whatever). Controller logic mostly live into Backbone view, and this is OK for front end developpement as logic is often really tied to the UI (as we are mostly coding interfaces). Backbone isn't coming built in with controller, but if you prefer this type of organization, just build your own.
2: Urls depends on your need. If you're fetching a full collection, set it up on the collection, if you're only fetching (or probably saving) one model, set it on the model. These too live well together.
3: About Router, if you're building multiple pages/sections on your app, use them. But beware of not using routes as action as you would do in RESTful APIs, this will most of the time brings problem eventually (user press back button, etc). So, use routes if you want to manage pages.
Hope this help !!
I will answer from experience:
Q: The second does the opposite. Which is the best practice for the "C" in backbones spin on MVC?
A: There is no Controller in current Backbone http://backbonejs.org/ - "C" happens either in View (most cases) or in Router (see below).
Q: The first tut defines urls in the Model, whereas the second defines it in the Collection. Which is the better practice?
A: There are cases when you don't need collections. In case when you don't, your model absolutely needs a URL. When you do have a collection, URL you specify for Collection will apply to its models.
Q: The second tut makes use of Backbone.Router, while the first one does not. Which is best practice?
A: Rule of thumb - you want to use Router in 2 cases: 1) when you want to have history, and 2) when you want to have permalinks. Otherwise you don't really need router.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
in the last months the development of mobile apps has become more and more a focus of mine. I already created a few apps with PhoneGap and also dived in into mobile frameworks like jQuery Mobile ans Sencha Touch.
In a next step I would like to use a mobile apps builder and I stumbled on Tiggr and Application Craft. There are probably even more.
So I wanted to ask if some people here already have experience with those two or maybe even another app builder and share it with us. As both seem to cover the same area and I am not so interested in learning them all. I would like to know if someone can tell me which is "better".
I know that there has been a big topic about PhoneGap vs Titanium Appcelerator that helped me a lot so I hope I can get some helpful answers about this topic as well.
Thanks for reading,
Marvin
I have been using Application Craft for about a month (on and off) and so far i'm really impressed. They seem to be putting LOTS of work into it: things have broken only a couple of times, never anything serious. Also, they are building really thorough documentation, etc. they host the apps for free, and they seem to be adding features etc all the time. I would bet that in a year or so they will be huge; quality services on the net tend to grow fast thankfully.
I hadn't heard about Tiggr until now. From what i can see on their site, it looks as though their free service is far inferior to what Application Craft offer. They may be worth a try too?
Hope that helps
I haven't specifically tried Tiggr or ApplicationCraft, but as you've already mentioned there are quite a few different app creation systems out there, all of which work in slightly different ways. Many, for example MobileRoadie or AppBaker, supply a series of pre-built templates that you can customise and plug together in various ways. This is great if their templates support the type of app you want, but there's often no scripting support so if you want something custom you need to pay for their developers to add the features you need, or you should go elsewhere.
If you want complete control over how your app looks and works then you should use a more IDE-like system with built-in scripting support. Things to look out for in such a system would be a good code editor, a way of immediately previewing your app inside the tools, decent documentation, support, and examples. If you're planning a cross-platform app, you'll want a system that can simulate your app running on different phone screen sizes, so you can tune your GUI appropriately.
AppFurnace is a new cloud-based app development platform that provides all of the above (I should point out that I work for AppFurnace, of course).
Tiggr Mobile is a great service! Check out thier tutorials on creating an app that will run on any mobile device at http://blog.gotiggr.com/. They've also received good press and have an impressive gallery of apps that users have created and submitted.
You should probably put NS Basic/App Studio on your list as well. It provides a complete IDE, including a 'drag and drop' interface for adding elements to your forms. The overall feel is something like Visual Studio. You can program in JavaScript or Basic. More info at http://www.nsbasic.com/app.
(disclosure: I work for NS Basic)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
The usual myth around MVVP is that originally Marting Fowler did create a Pattern called MVP and then Grossman make it evolves into MVVP.
Did they read the original MVC paper carefully ? MVC was presented as concepts and for example it never imposes one single model it did say that model could be splitted in multiple smaller models depending on the way one wants to model the system. So if one wants to create a passive view or a fat view what counts is the two-way binding between many views and the model.
So I'm astonished to read articles pretending that MVVP is some new modern invention, and two-way databinding in wpf is a new revolution, for me the industry has rather been very slow to reify concepts that was setup 40 years ago. That's the very cause of so "software crisis" because fundamental concepts were badly implemented or even lacking and programmers were prisonners of the industry vendors.
So here's the original paper
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
Show me what these "modern" pattern fundamentally contradicts MVC.
You need to do your homework! Martin Fowler is highly knowledgeable when it comes to UI patterns (and patterns in general). See his article on UI architectures:
http://martinfowler.com/eaaDev/uiArchs.html
Martin proposed a patten he called presentation model (PM) where the PM is a representation of the view which is independant of the UI controls in the view itself:
http://martinfowler.com/eaaDev/PresentationModel.html
He mentions how this pattern is easiest to implement with UI frameworks that pemrmit databinding, which reduces the need for 'plumbing' code.
Gossman first coined the term Model-View-ViewModel (MVVM), however most consider this to be the same pattern as PM, however, most consider MVVM to be a WPF / Silverlight specific version of PM, i.e. MVVM typically implies further conventions are followed, e.g. use of DataTemplates, ICommand, etc ...
Neither pattern are that similar to MVC, if you draw the dependencies to the three components of each pattern, MVC creates a triangle, whereas PM & MVVM are a line.
Most experienced developers take a pragmattic approach to patterns. They are a tool, pick the one that best fits your problem, and if you have to bend it a bit to make it fit, go for it.
Stop stressing - and write some code ;-)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Does anyone have any experiences in learning the language Eiffel.
Is the Eiffel Studio like Visual Studio?
Is it a good route to take to learn OOP?
etc.
I learned this language about 15 years ago and never regret it.
Eiffel is a bit different from mainstream languages and features some mechanisms not readily available in other environments. In some sense it's a bit more academic than mainstream.
EiffelStudio environment takes some approaches that are not present in average IDEs as well. (For example, it supports Pick&Drop facility which is similar to Drag&Drop, but does not require to keep mouse button pressed as you drag the selected item.) It provides pretty advanced browsing facilities, so in this sense it's quite close to Visual Studio. It also has several built-ins like Diagram and Metrics tools, recently added AutoTest, etc. You can have a look at EiffelStudio documentation to get an idea about its features.
Since the language lacks hacks to introduce basic types, supports multiple inheritance and generic types and integrates Design by Contract right from the beginning, it is extremely good as a learning tool for OOP even if you do not plan to use it on a day-by-day basis. For that purpose I'd recommend "Object-Oriented Software Construction", 2nd Ed. by Bertrand Meyer. It does not include the most recent additions to the language, but it does provide a good route to OOP as a whole.
I think it's the best route to take for OOP, since it does object orientation very well.
I haven't seen an oop language that is as clean and consistent with regard to object orientation. therefore it's beneficial for a student to see how it should be done right.
As a language, if you contrast it with the scripting languages such as python, rebol etc. it's more heavy-weight. Best for large projects where you want to maintain quality. It focuses entirely on proper object orientation. (so you will not see all concepts of programming, but OO is a major paradigm)
Its speed is very good, as it compiles down to C, so I only meant heavy-weight about the structure.
It promotes iterative development, and thought-out design, so that's also a good technique to have.
You can read the Eiffel Tutorial to get a thorough overview, but take it gently, as it's a hundred pages "tutorial".
I actually think students who are being taught OOP should learn on the easiest language possible so they struggle with the concepts more so than the language. I learned on both Java and C++. The former was OK, but the latter was a nightmare. Python would be my suggestion
With regards to Eiffel, I tried doing my PhD project in Eiffel and I ran into serious problems. I would definitely not recommend using the GUI as there is little to no documentation on it. Also the compiler is very buggy. I was constantly in touch with their support regarding completely bizarre behavior. For example putting a print statement would solve a compile time error!
Eiffel provides some of the best multiple inheritance options, but even that can turn into a nightmare sometimes. I remember inheriting from multiple classes which all inherited from one main class, then having to SELECT one redefined function out of them, or to have to RENAME a function.
The design by contract was a good addition, and the variant helped avoid infinite loops, but at other times you just looked like an idiot when you had checks like these (my Eiffel is a little rusty)
foo (something)
do
x = x + 1
ensure
updated: x == old x + 1
There are other minor problems too. Often times the Eiffel studio would get corrupted and you had to erase certain back up files to get it to work.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So far, most of my GUI programming has been done in C++ with the Qt Framework, I'd like to branch out a little bit and do some C# with WPF. Originally, I wanted to write something like Adium for Windows, but that seems a tad...ambitious for a starting project. I'm not even sure if you can call libpurple stuff from C#, but I'd like to find out.
However, it seems my imagination is rather lacking and I'm having trouble thinking of something that isn't either completely trivial (a text editor! a calculator! wee!) or rather hard (something with libpurple).
So, any suggestions?
I don't want to write a calculator (even if it seems a rather fitting starting project for a GUI framework)!
A long time ago I started the "Quest for the Perfect Project" with a few colleagues - the idea was that we'd try to do everything as well as we possibly could, fully test-driven etc, while learning WPF, WCF etc. We reckoned that Battleships would be a really good game. You can start off relatively simply, but there are lots of ways to extend it over time.
We never actually got anywhere with the project, mostly because we all ended up at different companies and I started writing C# in Depth, but I still think Battleships was a good game to use for learning.
Start off with a two player, single screen, local-only game, and then work out network play, AI, variations for more than two players, leagues, chat etc.
(When running as a single screen it would be seriously non-ideal as an actual game - each player would have to look away while setting up the ships to start with, and if any player wanted to see their own ships later on to get an idea of how close the other player was, that other player would have to look away. It would be great for making sure you've got a working game engine though.)
My favorite open source WPF application I've seen so far is Family.Show, a simple genealogy application that seems to use WPF really well. The source code is available on CodePlex.
(source: vertigo.com)
Try taking a look at Coding4Fun. There are a few WPF projects on there that might be of use to you, including a version of Sudoku. You can either use the articles to sow some seeds and try to develop the apps yourself, or just grab the code and pull it apart to see how it all works.
My usual starting point for these kinds of expeditions is to write a simple accounting program; money in/Money out with scheduling and graphing.
It turned out to be a pretty useful exercise when i started out with WPF because it gives you the scope for some pretty advanced stuff when you get around to visualizing the data (if you want to get fancy!) and also has a LOB edge to it meaning you're more likely to gain some commercially viable skills with it. I also used IsolatedStorage in mine which was fairly useful.
Anywho, that's my suggestion.
Make a game. Or have a look at the Silverlight Showcase and find something interesting and make it, but better.
Quite another interesting game is what Tess Ferrandez (she an escalation engineer in the ASP.NET team at Microsoft) wrote on her blog, it's a game called "Traffic Jam", similar to "Parking Lot" on the iPhone. It's written in Silverlight, but you could easily make it a Windows WPF application.
Write a spreadsheet program.