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.
Related
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'm looking for a socket.io client for Scala. I'm well aware of this, but I cringe at the idea of using it in Scala as it wouldn't feel quite natural nor would it allow for an idiomatic implementation. Does any of you, thus, have a suggestion as to where could I find a Scala client?
If so, just the lines for SBT and a link to the doc will suffice as an answer ;)
I'm afraid I don't know any already implemented libraries or apparent solutions for Scala. But I'll present two very simple approaches that should be very easy to use if you have the time to DIY :-)
But of course it really depends on what you want. As you probably already could imagine a plain WebSocket implementation of Java's standard library can be quite efficient if you need to process simple requests. I found one at scala-lang.org implementing a server calculating random numbers. If it is of interest there's also something brewing at the nightly build which might reveal some handy tricks.
If you want to go for simplicity and for pure Scala in all its might the Actors (in particular a RemoteActor) are immensly powerful. It requires Scala on both ends naturally, but it gives you a messaging-system almost instantly. This is a pretty good start-guide if you aren't already familiar with them.
Anyway. If no good library surfaces I hope this helped. Good luck.
Now i know that this one is actually not a very technical question but one that has been bothering me for some time. Actually we are using a lot of C++ and PHP at our company and some of our developers are really hoping for a new and modern language to come by to help us getting more productive. I have been talking about what scala can do and the other coders seem to gain some interest in the language. The tough job is, how do you convince your boss to consider scala as a language for the company. I saw the presentation "Sneaking Scala into your company", but it deals with the situation that you are using Java at your company which we don't.
How do you fight of the usual "that is just esoteric stuff" and "we can already do that in $LANGUAGE" arguments. I was planing to give a talk about Scala, and since I don't have much time I need ideas how to get people interested in the language rather then setting of reactions like "currying? we can already do something like this with boost::bind".
How did you guys do it?
Regards,
raichoo
EDIT: Gave my talk yesterday, people were very excited. My company is going to give it a try! Thanks for all your suggestions.
If you don't already have killer arguments, what are you basing your reasoning on that Scala will make your company more productive?
Don't like something then hunt for reasons to use it at work. Let the reasons speak for themselves..
"A hammer looking for nails"
Using it to do some stuff around the side, as datamigrations, testing and similar things will make sure the necessary experience is built and can give it some exposure.
ScalaTest is really nice to help with acceptance/integration testing. (Yes, I know it is nice for unit testing, but I do not see that immediately happening with C++/PHP target code, and it would probably be unwise).
Proof of Concept and other Prototypes are great for 2 reasons
1) It showcases the capabilities
2) You are certain they will be thrown away if you have to reimplement them in C++/PHP
Now a bad time to introduce Scala would be when you REALLY need it : hopes will be high, it will not immediately work as intended, hopes are dashed and everybody will blame Scala. As a result it will be burnt for a long time in the organisation.
Sooner or later some suit will think it was his idea to introduce Scala and use it on a formal project. If that project is moderately successful, then it is sold.
These kind of changes are complicated people issues, and the harder you push, the harder you will face push-back. On the other hand the persistent mind can move mountains.
Redo some of your work related code in Scala and compare KLOC, code structure and performence, if it looks and works better, show it to your peers and your managers.
In other words:
Talk is cheap. Show me the code.
-- Torvalds, Linus (2000-08-25)
In case of our company (and I assume, many companies share the same scenario), move to Scala (from Java) was initiated by tech people, who 1. wanted to work more productive writing code (living in the 21st century utilize modern approaches), 2. have less troubles building concurrent applications (Actors concept promoted by Scala is a way simpler than Java thread-based concurrency) 2.1 have a simpler way of building scalable staged event driven architectures.
In our company, transition to Scala was more or less simple, because Scala was literlly sold to business people as a library to Java :) -> from their POV, we're still using the same platform (JVM), application servers, etc., but developers are having more fun from their work, and therefore, are more inspired and work more efficiently.
Maybe you could pitch Scala by showing off the suite of tools that is used for development? For example, if you are not already using Eclipse in your company, show your execs a demo of what a modern IDE can do for your productivity.
There is a book called "Fearless Change" (Linda Rising) that describes a pattern language for "powerless leaders" (I LOVE that role title!). SE-radio had a really motivating interview with the author: http://www.se-radio.net/podcast/2009-06/episode-139-fearless-change-linda-rising. Listen up on that interview to collect a few non-technical strategies that can help you in this struggle!
I haven't used Scala yet for any real business code, but I know people who have.
One group used it to write a tool to analyze log files. So they didn't use it for mission-critical business code, but for a non-critical tool to support the project.
Another person I know is an architect and he just went and wrote some Scala code on his own for some production code without telling his manager. After the code was deployed successfully he did tell it. One of the things he mentioned is that because Scala runs on the JVM, the people who support the application don't even notice - to them, Scala is just another library that's included with the application (they were already used to the JVM). Ofcourse this approach is risky and not everybody will be in the position or be willing to do this.
You could start small - use it as your personal preferred scripting language for small things that you need yourself. Tell your fellow developers about it and make them enthusiasts too. If they also start using it then you can step it up to make some side code for your project (such as for example that log analyser tool).
This isn't a really easy task. I would concentrate on the fact that you will be able to produce code and therefore products faster and with a higher quality. That's always the two reasons, business wants to hear from you and will listen to.
Maybe you can show an example of 1-2 very small projects you did in your company with C++/PHP and compare the effort, quality etc. with a similar/the same implemenation in Scala? This would be very impressive and should also convince people who are not on the coding side.
There was a very good talk at Scala Days 2010 by David Copeland:
Sneaking Scala into your organisation
The executive summary: Testing. You can use Scala for testing without affecting release code.
I can see from release notes and such that there has been
many improvements in lift 2.0 for building REST stuff,
but I'm unable to find what has been done or how to
use the new stuff compared to the old.
Does anyone know of such documentation, blog entries, examples
or similar for how to use REST in lift 2.0.
Ideally I would like something along the lines of the links below
updated for lift 2.0, or something similar.
Perhaps someone here have such examples handy or know where
to find it?
http://blog.m1key.me/2010/07/rest-with-scalas-lift-framework-part-1.html
http://blog.m1key.me/2010/07/rest-with-scalas-lift-framework-part-2.html
I'm a REST-enthusiast in general and currently evaluating various aspects of Lift's support. I've recently blogged by thoughts on URI matching and Content Negotiation here and here. This is an ongoing series at this moment.
I really like what I see so far. The framework is very flexible. Even if you find an aspect of REST-support is missing you can extend the functionality with reasonable effort.
Lots of things have changed which make REST APIs a lot easier to create. Here are two links to articles which describe the new methods for building them. You should also look at the google group as there are lots of examples in the archives:
http://blog.getintheloop.eu/2010/3/29/multi-format-rest-services-with-lift
http://www.assembla.com/wiki/show/liftweb/REST_Web_Services
I've been evaluating a framework that on paper looks great. The problem is that the sample code is incomplete and of poor quality. The supplied reference implementations are for the most part not meant to be used (so they can be considered as sample code as well) and have only succeeded at confusing me.
I know that it's common for things to look better on paper, but my experience with the sample code is turning me away from further investigation.
Do you let poor code samples change your judgment of frameworks/libraries? So far my experience has been similar to the "resume effect": if someone doesn't put the effort into spell checking their resume, they probably won't get the job...
For me, it does. I tend to want to avoid libraries where the code samples are incomplete. If the library is open source, I will overlook it, since I can directly look at the code and see if the library's internals are reasonable, and I know that, if there is a problem someday, I could (if I had to) fix it.
If the library is commercial, and their samples and/or documentation is poor, I look elsewhere. I just see it as risk management - poor samples make me fear the quality of the library in general.
No matter how good something is on paper or in theory, it can still be crap when programmed.
I think this is a valid reason to turn away from and evaluate other libraries. As a potential user of a library a lack of documentation and/or bad code samples gives the impression that the library is not yet mature enough for use by third parties. In time it may well gain the missing pieces but until then I think its reasonable to look elsewhere.
I was recently evaluating the multitude of blogging applications that people have uploaded to github.com I quickly skipped ones that no documentation as they obviously weren't ready for others to use. The ones that remained at the end had a good README with info on how to get the app up and running as well as an online example of the code running.
Poor code samples combined with poor documentation will make me turn away from a library unless there is a compelling reason to use it. However, a library that has either good code samples or good documentation is usually worth using. (Assuming that the library itself otherwise meets my needs.)
If I can't find good examples (and/or documentation) illustrating how to use the library, I'm definitely less likely to use it - just as a practical matter, it'll be harder for me to figure out how. But I don't care what the code that implements the library itself looks like. I don't think I'd choose one library/framework over another just because the developers of the one have shown an ability to write cleaner code (which is what I understand the "resume effect" to mean).
Lack of documentation and examples makes me a whole lot less likely to use that particular library. It's not worth my time testing and trying to figure out how a black box works if there are alternate solutions to the problem out there.
Yes, definitely. Every library should come with a simple example using program and a CLI interface (for very simple libraries with <3 methods and <10 hooks, one example should suffice).
And why does your framework "look great" if it's so hard to use that even the original coders make mistakes using it?
It certainly matters to me. Evidence of sloppy/incomplete coding and poor communication decreases my confidence that the actual implementation code is stable and robust.
Myself yes, but there must be people out there who aren't turned off by this otherwise there are plenty of open source projects that would have died a long long time ago.