Related
I'm using ScalaJS with Play. Many of the models I'd like to use on both JS and JVM platforms involve dates and times. Given the lack of a cross-platform date/time library, how are people approaching this?
Things I know about:
scalajs-java-time project (https://github.com/scala-js/scala-js-java-time) to port JDK8's java.time api to Scala.js. Unfortunately, it's far from complete and judging by the commit logs, seems to have stalled.
https://github.com/mdedetrich/soda-time is a port of JodaTime to Scala/Scala.js. But it's not ready for production use.
An old post at https://groups.google.com/forum/#!topic/scala-js/6JoJ7x-VxLA suggests storing milliseconds in shared code and then doing implicit conversions on each platform to either js.Date or JodaTime. But we really need a common interface, which this doesn't give.
Li Haoyi's excellent "Hands-on Scala.js" has a simple cross-platform library (http://www.lihaoyi.com/hands-on-scala-js/#ASimpleCross-BuiltLibrary) that could, in theory, be extended to come up with an API in /shared that delegates to JodaTime on the jvm and Momento on js -- but that sounds like a lot of work.
(added later) https://github.com/soc/scala-java-time is based on an implementation of java-time that was contributed to OpenJDK. The README claims that most stuff is working. Right now, this looks like the most promising approach for my needs.
Any advice from those who have gone before me? Right now the fourth options seems like my best bet (with the API limited to stuff I actually use). I'm hoping for something better.
I was in the same boat as you, and the best solution I came up with was cquiroz's scala-java-time library. From reading the comments to your question above, it appears you landed at the same place eventually!
I came here from a google search, and given how much better this solution is than the alternatives you mentions above, let's consider marking this question as resolved for future visitors.
I want to learn Lift. Unfortunately, all documentation which I tried either obsolete, unreadable, incorrect or combination of the above. I tried the following:
Simlply Lift. Some things from the book I tried lead to errors.
Exploring Lift. The structure of book is very bad. It's hard to read and try out code in the wild at the same time.
Lift in Action. The same as the previous but you need to pay for it.
P.S. I've seen similar questions. Most of them were asked a long time ago. Did the situation improve from the time of that writings?
P.P.S. Are there any other type safe scala web frameworks (Don't offer Play 2.0. It's not typesafe. I don't see any reason to create it in Scala).
It is unfortunately true that the state of Lift documentation is uneven at best and there are huge gaping holes.
However, the Lift community is just full of awesomely helpful people.
My recommendation is not to play around, but rather to try and implement something. If you get stuck, ask specific, direct questions about what you're trying to do, how you're doing it and why it isn't working.
So far, though I would wish for better documentation, I've been able to get every answer that I needed either through Google or on the Lift mailing list - though I expect I might ask more questions here in the future.
The Lift documentation is not its strong point. The philosophy is more "try and ask if you have any problem". Here are a few tips:
Assembla
One ressource that is really useful is http://www.assembla.com/wiki/show/liftweb, there are a lots of examples so you can progressively learn how it works.
Mailing List
Otherwise you can always use the mailing list if you have specific questions even if in my opinion it is really hard to explore it fast in order to solve a problem which was already encountered. http://groups.google.com/group/liftweb
Stack Overflow
Finally, a small community is present on Stackoverflow so feel free to ask in here. This is a good way of looking for answers and creating documentation in the same time.
Source code
Don't hesitate to explore the source code and the scaladoc if you have specific questions/doubts about the behavior of a function, they are often short and even sometimes commented! http://scala-tools.org/mvnsites/liftweb-2.4-M4/#package
Have a look at the Lift Cookbook: http://cookbook.liftweb.net/
"Simlply Lift. Some things from the book I tried lead to errors."
What exact type of errors did you have? Have you tried to follow it with "Simply Lift" examples that you can download from GitHub
https://github.com/dpp/simply_lift?
Only errors I had were related to my lack of experience with SBT, but that's another story.
I have started with Lift mostly from that source (Simply Lift + examples) and in combination with its great community and Google (ChrisJamesC has listed the main links really nice) it was quite okay for me.
I would suggest you to work out all examples given in the "Simply Lift" tutorial or at least work them out unless you feel comfortable enough to jump right "in media res" and try something by yourself. That was the best way of learning Lift for me.
Also, whenever you got stuck somewhere and can't find solution on the web, your questions would be welcome and answered on the Lift Google Group (https://groups.google.com/forum/?fromgroups=#!forum/liftweb). David Pollak is very often right there to answer your questions directly so I have only words of praise for this framework's community and Lift's
creator.
P.S. Lift's documentation could be better organized, some stuff could be better explained for sure, but IMHO it was just too small a price I had to pay to enjoy such beautiful framework. Learning curve is steeper than with Play, especially in the beginning, but after I "survived" the very first week it was almost impossible for me to give up of all of its advantages and original concepts (Lift's "Seven Things") and switch to another framework.
I am about to develop an application for iPad and it has enormous amount of background thread network calls.
I would like to know which one will be better? ASIHTTPRequest still works but not maintained. However few sources says AFNetworking framework creates lots of complications.
Update (September 2013)
It's been nearly two years since I originally wrote this answer, and quite a lot has changed. AFNetworking is about to go into version 2.0 and has a thriving developer community, whereas ASIHTTPRequest is pretty much dead. Additionally, AFNetworking has dozens of great helper libraries and classes available for handling things like OAuth, Amazon S3, and the like. It's so popular that there's several books available on it.
Given this, there's no reason at all to keep using ASIHTTPRequest. My original answer is below, so if you're still interested do read on - just bear in mind I would now recommend without a doubt not using ASIHTTPRequest and going with something more modern (namely, AFNetworking, but other options are available).
Original Answer (December 2011)
How much time have you got? Here's my thoughts, although as a subjective question I don't think there's a right or wrong answer.
I lead a development team that works on commercial apps for sizeable clients, and some of my colleagues are always on the look-out for new libraries that can make things easier. Currently I guess the vast majority of our networking uses ASIHTTP. We took a look at AFNetworking about six months ago, and decided at the time we'd stick with what we know. ASI has been around for a while, and there is far more documentation and helpful advice available online for it. It is a solid codebase, and been around long enough to have gained a lot of traction and respect.
That said (and hopefully people who disagree with everything I've said above will read on!), I think if you're starting afresh now is the time to move on to something else. Even the developer of ASI thinks so. Given all of the changes that have come with iOS 5, I think a modern actively maintained framework like AFNetworking (and there are other options, like RestKit) is a good choice.
Now, you're right to say some people have trouble using AFNetworking in their application. But equally, a quick google reveals many people who had problems with ASI (valid or not)! I think whatever framework you go with, someone somewhere will have had trouble with it, either through something genuine wrong with the framework or their own limitations.
So with all this in mind I think I'd dive in to AFNetworking, and see how you get on! One of my new year resolutions will be to migrate over to a new networking library, and I think it will probably be AFNetworking.
From Author's Comment:
A little update: I've actually really enjoyed using AFNetworking, and in many ways it's considerably better (probably not the right word: 'refined', maybe) than ASI. That said, you shouldn't go into it expecting a 'like for like' replacement, and there are certain things you may want to consider other options for (Amazon S3, which ASI supported out of the box for example). But I'm generally really pleased, and find it a clear, well documented library. So if you're looking to move from ASI to something else, you really can't go wrong with AFNetworking...
https://github.com/BoydYang/BYRequest
BYRequest based on MKNetowrkKit, but it works like ASIHttpRequest, so you can easily migrate your project from ASIHttpRequest to BYRequest and also enjoy ARC.
I realize that this may be subjective but I truly need an answer to this and I can't seem to find anything close enough to it in the rest of the Forum. I have read some folks say that the framework (any MVC framework) can obscure too many things while others say that it can promote good practices. I realize that frameworks are great for a certain level of programmer but what about individuals starting out? Should one just focus on the language or learn them together?
I think web development is way more than anyone grasps when they first start getting into it! Read this and know that it is all optional...but required to be really good at what you do.
I suggest that you spend time learning your language first. I would suggest learning C# simply because it is vastly more marketable and it is usually directly supported in most of MS products. By learning C# - programming in ASP.NET, console apps, servers, services, desktop apps, etc. will all be within your reach. You can program for most of the MS products as well as on many Linux type platforms.
Once you have this down then you can move to programming for the web as programming for the web has some intricacies that most other environments don't have. Concepts such as sessions, caching, state management, cross site scripting, styling, client side vs server side programming, browser support, how HTTP works, get vs post, how a form works, cookies, etc. are all at the top of the list of things to learn separately not to mention learning the ASP.NET base frameworks and namespaces.
Once you have the programming language down and then the concepts of web programming I suggest that you pause and learn database design. Don't worry about performance just yet...try to first learn good design. Performance will come next. A good start for you is Access (blasphemy I know). It is easy for a beginner to work with. And it translates into a more robust platform such as SQL Server easily. Learn at the very least some SQL...but I suggest that you learn as much as your stomach can handle. I heard someone say that SQL is like the assembly language of the database. The number one thing that slows an application to a halt is piss poor database design and poor queries. Once you have this knowledge - stuff it away in the back of your mind and take a look at a good ORM. NHybernate is probably best at the moment but is more complex that the basic learner needs. For that reason I currently suggest getting LINQ to SQL up and running as it is SUPER EASY to work with. Then look at Entity Framework (although I still think it sucks...and you should wait till EF 2.0...ERRRRR...now 4.0 released with .net 4.0). Then NHybernate.
Now is the time to start to understand the infrastructure that is required by web development. You may bump your head against this as you learn some of the web programming stuff. But you need to understand the basics of DNS, IIS, load balancers, sticky routing, round robin, clustering, fault tolerance, server hardware setup, web farms, cache farms (MemCached Win32, Velocity), SMTP, MSMQ, database mail queuing, etc. Many people may say you don't need this. That there will be some knowledgeable network admin to help you out here. However they generally know things that impact them...not you. The more you know here the more valuable you will be to the company that hires you.
Now you can get into the details of best practices and design patterns. Learn about the basics such as repository pattern, factory pattern, facade pattern, model view presenter pattern, model view controller pattern, observer pattern, and various other things. Follow Martin Fowler and others for suggestions here. Take a look at concepts such as inversion of control, dependency injection, SOLID principle, DRY, FIT, test driven design, and domain driven design, etc. Learn as much as you can here before moving to the next step.
NOW you can think about frameworks! Start by creating a basic application with ASP Classic (comes with IIS for free!). This will give you a flavor of a no frills web development environment. Take a look at ASP.NET web forms (briefly) to see how MS attempted to make things easier by hiding all the complex stuff (which you now know how to manage on your own from your readings of the above materials!!!). Now you no longer need ASP.NET Web Forms. Move immediately to ASP.NET MVC. The MVC framwork gives you all the power you need to create a good easily manageable web application. If you build something really big no framework for pure web development may be able to deal with what you need. However MVC is way more extensible for such UBER custom scenarios.
Now that you have made it through the journey to ASP.NET MVC you can take a look at things such as Microsofts Enterprise Application Blocks (such as they use at MySpace). Take a look at Elmah error logging (a must have). Look at how to build a custom SiteMapProvider for your MVC site. If you need to get into searching stuff understand Lucene.NET.
And if you made it this far...you are ready to figure out the rest on your own as it comes up! Have fun. There is a lot of room in this space for a person with some understanding of all of the above concepts.
You'll be using SOME sort of framework. The question is, what level do you want to learn at?
You'll probably not care to learn about asynchronous I/O and mutlithreaded vs. select/poll styles of web servers.
So then, your language of choice is going to provide a layer atop this, the languages preferred "web interface" API. For Java it's Servlets, the lowest level you'd typically code at for server side web applications.
You should find what this "lower level" layer is in your language and learn the API at least. You should know basic HTTP like status codes, cookies, redirects, POST vs GET, URL encoding, and possibly what some of the more important headers do.
You'll then come to appreciate what these higher level frameworks bring to the table, and be better able to evaluate what is the appropriate level of abstraction for your needs/project.
Web development requires a certain degree of organization, since it relies so much on separation of concerns. The browser, for example, is designed to display data and interact with the user. It is not designed to lookup data from a database, or perform analysis. Consequently, a web development framework can help provide services that are needed to make the browser experience a practical one.
The nice thing about employing a platform is that it will provide core components essential to the making of any web application that you won't (and shouldn't) have to think about, such as user membership, for example. Many of the design decisions and deep thinking about how to implement these services has already been done for you, freeing you to focus on what you actually want you application to do.
Of the available frameworks, I find that frameworks that implement the MVC (model-view-controller) pattern are very practical. They clearly organize different functions of web development, while giving you full control over the markup presented to the browser.
All that said, you will need some fundamental skills to fully realize web development, such as HTML, CSS, and a core programming language for the actual underlying program, whether you use a platform or not.
I don't think I agree with the Andrew. I don't think learning C is a pre requisite for web development. In fact, learning something like Javascript, Action-script or PHP is often easier due in large part to the vast numbers of sites and tutorials available, and are enough to expose you to the fundamentals of pretty much every programing language. Variable, Conditions, Loops and OOP. I just think learning C# introduces a lot of learning that isn't really relevant to web development such as pointers and memory management.
As for wether you should learn a framework first? Definitely not. Never ever. You need to be able to stand on your own two feet first and be comfortable with HTML/CSS, Server Side Scripting (PHP/ASP/Python/Ruby whatever) and love it or loathe it, but you're going to have to have a decent understanding of Flash and Action-script.
The order in which you learn these is entirely up to you. But my learning plan would go like this...
Start with HTML. It takes about half an hour to get the basics (it's made up of tags with attributes, end of lesson 1) and it's good to get it out of the way first.
Then start leaning CSS. You'll get the basics again, very quickly. But CSS is a minefield so expect to spend the rest of your life figuring it out.
Next up Action-script. Most people wouldn't agree with me, but bear with me. HTML and CSS aren't programming languages. Action-script is. And learning a programing language for the first time is difficult and tedious. The advantage Action-script has over most other languages is that the results are very visual. It's enjoyable to work with and you can sit back and take pride in your accomplishments at regular intervals. This isn't possible with server-side scripting languages or Javascript and there's a whole host of stuff you need to learn to get server side scripting up and running. You can't build space invaders in with PHP for example.
I've changed my thinking here. I would encourage beginners to ignore ActionScript and focus on Javascript. I still believe that being able to see stuff on screen quickly is a good motivator, but I would encourage people to look at canvas tag tutorials and frameworks. Javascript has come a long way since 2009, and is now the lingua franca of programming, so it's incredibly useful. My initial point about HTML and CSS not being programming languages still stands.
Then, you can start with your server side language. At the same time, you're going to have to figure out the database stuff. I recommend PHP and MySQL because it's free.
Again, I've changed my thinking here. I would encourage beginners to use Javascript on the backend (Node.js), and split their database learning between relational databases and noSql solutions such as Mongo.
Then.... learn your framework. Or better yet, roll your own. That's what I've been doing and it's supercharged my learning.
If you're getting into web development, You HAVE to know how those building blocks work. You don't have to be an expert in all the areas, but you should try to become an expert in at least one of them. If you start learning a framework before you get the fundamentals you'll be in a sticky middle ground where you don't understand why things don't work which will infuriate you, and anyone who has to work with you.
you should learn how to use framework because it would be helpfull for u in the future also it is easier to learn.
MVC will help you a lot .. trust me ... i was developing web project not using mvc and it is like mess ... (in the past there are no well know mvc and i never heard about it)
Short version: yes, and then some.
FWIW : This more generic answer may be of use to someone out there.
What: Frameworks take out tedium of using boiler-plate code again and again. They hide complexity and design issues under wizards and conventions. They also use special libraries, design patterns etc. in ways that are far from obvious to a beginner.
So using a framework is good for getting things done without knowing exactly how - like using an ATM without knowing the internals. You just add your code bits in certain places and things 'just work'.
HTML > CSS > Ruby > SQL > Rails/Javascript framework > Libraries would make for a good learning track. Rest you learn as you go along by being curious, hanging out on forums or as extended learning as need arises.
HOW: The problem starts the minute you step outside simple text-book examples (i.e. when you try to get it to do something even a bit different).
Decoding cryptic error messages when it seems like you've done everything right but things still don't work. Searching on error strings in forums may help out. Or just re-starting from scratch.
Reading up articles and books, videos, trial-and-error, hard-work, search-engines, stackoverflow/forums, local gurus, design articles, using libraries, source-code browsing are a good way to climb the learning curve gently and on a requirement basis.
Working-against-the-framework is the number one problem for beginners. Understanding what the framework expects is key to avoiding white-hair in this phase. Having enough insight to manually do what the framework automates may help reduce this second-guessing effort.
WHY: For more advanced debugging/design, it's good to know what the framework is doing under the hood esp. when things don't work as you planned. Initially you can take the help of local-gurus or forum gurus who've already done the hard work. Later as you go deeper you can take on more of that role. For example there's a "rebuilding rails" book which looks under the hood of Ruby on Rails.
Note: Some of the tips are oriented towards Ruby/Rails but you can easily substitute your favourite language/framework instead.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Can you suggest some good MVC framework for perl -- one I am aware of is catalyst
The need is to be able to expose services on the perl infrastructure which can be called by Java/.Net applications seamlessly.
I'll tell you right now that Catalyst has by far the best reputation amongst Perl developers in terms of a rapid application development MVC framework.
In terms of "pure" MVC I'm not sure there are even that many "mature" or at least production-ready alternatives.
If Catalyst doesn't seem right to you, then you could build upon the lightweight framework CGI::Application to suit your needs or take a look at some of the lesser known MVC frameworks like PageKit and Maypole.
Since this old thread popped up, I will mention two exciting new additions to the Perl MVC world:
Dancer (CPAN) which is heavily influenced by Ruby's Sinatra, known for being very lightweight
Mojolicious (CPAN) which is written by the original developer of Catalyst to use what he learned there, it has no non-core dependencies, with very modern builtins (HTML5/CSS3/Websockets, JSON/XML parsers, its own UserAgent/templating engine)
(N.B. I have used Mojolicious more than Dancer, and as such if I missed some features of Dancer that I listed for Mojolicious then I apologize in advance)
Another alternative besides the ones already mentioned is Continuity; however, it is (as the name is meant to imply) continuation-based rather than MVC in the typical sense. Still, it’s worth mentioning because it is one of the better Perl web frameworks.
That said, I like Catalyst much better than any of the alternatives. And it’s still getting better all the time! The downside of that is that current preferred coding approaches continue to evolve at a fairly hurried clip – but for the last couple of versions, there has been strong emphasis on API compatibility, so the burden is now mostly mental rather than administrative. The upcoming port of the internals to Moose in particular is poised to provide some excellent benefits.
But the biggest argument in favour of Catalyst, IMO, is the Chained dispatch type. I have seen nothing like it in all of web-framework-dom, and it is a most excellent tool to keep your code as DRY as possible. This couples well with another great thing that Catalyst provides, namely uri_for – a method which takes a controller and a bunch of arguments and then constructs a URI that would dispatch to that place, which it returns. Together, these facilities mean that you can structure your URI space any way you deem right, yet at the same time can structure your controllers to avoid duplication of logic, and keep templates independent of the URI structure.
It’s just brilliant.
Seconding comments made by others: Catalyst (which more or less forked from Maypole) is by far and away the most complete and robust of them. There is a book by Jonathan Rockway that will certainly help you come to grips with it.
In addition to the 'Chained' dispatch type, the :Regex (and :LocalRegex) dispatch methods provide enormous flexibility. The latest app we've built here supports a lot of disparate-looking URLs through just a handful of subs using :LocalRegex.
I also particularly like the fact that you are not limited to a particular templating language or database. The mailing list (and the book) both have a preference for Template::Toolkit (as do I), and DBIx::Class (we continue to use Class::DBI), but you can use pretty much anything you like. Catalyst is marvelously agnostic that way.
Don't be put off by the fact Catalyst seems to require half of CPAN as dependencies. Once you get it up and running, it is a well-oiled machine. It has reached a level of maturity now that once you come to grips with it, you find it 'fades into the background'. You spend your time solving business needs, not fighting with the tools you use.
It does what it says on the tin. Catalyst++
Been playing with Squatting the last few days and I have to say it looks very promising and been fun to use.
Its a micro webframework (or web microframework ;-) and is heavily influenced by Camping which is written in Ruby.
NB. Squatting (& Camping) don't have model components baked into the framework. Here's the authors comments on models... "Models? The whole world is your model. ;-) I've always been ambivalent about defining policy here. Use whatever works for you"
There is also CGI::Application, which is more like the guts of a framework. It helps a person to write basic CGI's and glue bits on to it to make it as custom as they like. So you can have it use hardly any modules, or just about everyone under the sun.
Catalyst is the way to go. There is also Jifty, but (last time I looked), it had terrible documentation.
If you are already aware of Catalyst, then I recommend focusing on it. It is mature, well-documented, and has a very large user-base, community, and collection of plug-ins.
For your problem I would take a look into Jifty::Plugin::REST which allows access to models and actions using various formats.
Let me just say that Jifty doesn't have terrible documentation. However, most of included documentation is API documentation, but there is very low-noise mailing list which has useful tips and links to applications.
Wiki at http://jifty.org/ is another resource which has useful bits.
If your goal is to make video store (my favorite benchmark for 4GLs and CRUD frameworks) in afternoon, it's really worth a look!
Another options is Gantry when used in conjunction with the BigTop module it can reduce the time it takes to build simple CRUD sites.
There is also Clearpress which I can recommend as a useful database backed application. It needs fewer dependencies than Catalyst. We have written a few large applications with it, and I run a badminton ladder website using it.
I have built some applications with Kelp, it's easy to learn and very helpful.