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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm a developer who is making an app without a graphic designer for the first time. I am competent at making user interfaces that fits conventions and the Apple Human Interface Guidelines, but when it comes adding that extra layer of decoration to make the app sexy, I'm totally inexperienced.
Does anyone have any pointers or resources for helping developers such as myself act like graphic designers, in particular for iPhone apps?
I have a technical knowledge of photoshop, without having an artistic ability with it. I like to believe that I have a good eye for judging aesthetics, but I've never been good at creating something aesthetically pleasing from scratch.
"Acting as" requires being one, so learn the basics of graphic design. One popular book for beginners is The Non-Designer's Design Book. It's not about Photoshop, it's about recognizing why a design works to improve your judgement. There is more logic behind it than you may think. Usually being pleasing is the same as conveying useful information, "design is how it works as much as how it looks".
Review screenshots of existing iOS apps: Pttrns, Well Placed Pixels, Beautiful Pixels, or keep your own collection using LittleSnapper and CandyBar.
Unfortunately most tutorials are step by step instructions to reach a goal, but they don't bother much in why or how combining certain effects works. Then there are a lot of subtleties which you will have to dig in blog posts. Erik Tjernlund posted a good link (flyosity.com), here is another (bjango.com). These details create immediate trust from the user. There are plenty of tutorial sites on Google, but learning PS is a long-term goal.
An (offtopic) option now is to buy professional services. Example, Articles from Sophia Teutschler got help from the IconFactory. It's cost effective to invest your time in what you do best to pay for what they do best.
I really like Mike Rundle's (#flyosity) blog post – "Crafting Subtle & Realistic User Interfaces" – as a good, hands-on introduction on how to think about creating beautiful user interfaces. Follow some of his advice and your apps will automatically look much better.
To get inspiration, I highly recommend the Pttrns site. Look at how different apps solve common tasks.
My last advice is to practice a lot. My experience is that using the most commonly used tools (Photoshop and Illustrator) doesn't come naturally for us developers. Seeing a professional using these tools can sometimes be a real eye-opener. Especially workflow and how they use the tools to guide them in the creative process.
I am frequently visiting this website: http://app.itize.us/wp/
Not for directly copying others design or functionality but I always get ideas on how to design GUI elements here, often by mixing many of the different styles. I will also recommend you to just play with all of the different layer options you get when you double-click a layer in Photoshop, learned a lot by doing that!
The Web Designers Guide to iOS Apps is excellent but it does focus on NimbleKit. If you're not using NK the design discussions are still valuable.
You can follow tutorials here. I am not vary much familiar about photoshop/illustrator but may be these tutorials be helpful.
Having a "good eye" and knowing what looks nice is good, but if you don't have that initial "vision" then you will be spending a lot of time playing around until you stumble on the design that looks good and even then you may never reach that point.
As developers, we are very good at following the guidelines put down by Apple and making sure that we follow those - after all it's a nice logical set of rules to follow and that's exactly what we do when we write code - follow logical rules.
Unfortunately the design side of things doesn't have rules that we can follow. Yes, we may be technical at using Photoshop or some other drawing application, but when it comes to actually having that spark of inspiration, that's not something we can just click a button for.
Looking at other applications is one way to go. But then you may end up having an app that looks like another app or a collection of a number of apps and then you may have problems with a fluid user interaction.
My own approach to this problem was to go out and find someone who is really good at doing that art stuff and working with them. I struggled for a long time designing my own stuff, but looking back, it was obvious it was a developer (me) doing the design. I'm not sure what it is, but there's an extra something that these graphic artists seem to be able to do that I just can't get and that makes all the difference.
But the flip side to this is that he can't code. Sometimes it's best to just stick to what you're best at.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am working with a small team (2 others) of developers that are geographically dispersed, and I'm looking for good ways for us to collaborate on specs... We're thinking we might use Google Docs to write the spec in so we can all have access to modify it in a central location.
What have you done? What good ideas do you have?
If you have an intranet or VPN, I would actually consider installing and using a small Wiki for these specs.
Compared to Google docs you get:
Much better versioning and change tracking (IMHO)
Much easier to start new documents for subsections
An actual markup rather than WYSIWYG (a matter of taste, I prefer LaTeX to Word).
Possible to attach variety of other file types
Very easy to backup
Very easy to create an offline version
You don't have to worry about storing sensitive materials elsewhere.
The disadvantage is that it is not WYSIWYG, which may or may not be an issue to you.
Of course, you can pick a Wiki implementation that supports a better editor, and possibly even a synchronous collaboration one.
Google Wave - exactly what it's meant for - collaboration
IMHO, a word processor is the wrong tool for a programmer. A spec should be written in a plain text editor, and utilize lightweight markup such as reStructuredText, AsciiDoc etc.
The benefits of such an approach are:
There are excellent tools to manage plain text, that are already in the hands of programmers (VCS, automated build systems, diff, patch, programming editors, grep, etc.)
A markup language allow for expressing intent rather then formatting.
That in mind, a Wiki seem to be the obvious choice.
Personally my tool chain of choice is:
reStructuredText as the markup language.
Trac as a Wiki
Firefox + the it's all text extension
Emacs + rst-mode
The choice of technology is one issue and Google docs is a good choice IMHO. But the real challenge is how to manage the process e.g. divide the tasks.
My suggestion is to first make sure that the platform and all related technologies are decided-upon as best as feasible. Then, compose a a thorough table of contents. A well-designed TOC will allow you to divide tasks properly and not "step" on each others' work. From then on you each "flesh" out your assigned sections as well as review each others' work.
In effect, each TOC subsection becomes an atomic unit of work that can be assigned and maintained by an individual who is also accountable for said section(s).
Good luck!
I think it depends on
How heavily into writing the specs you all are
If you're likely writing at the same time
Whether you intend to publish the specs.
Google Docs is nice and easy to get started with. It's also great that you can now export folders all at once. Still, for something that's going to be published to the web, a wiki or general cms is a better presentation vehicle. A wiki will also integrate with your existing site.
If you've got small specs, primarily written by one person then use whatever tool is available where you're hosting the project code or website. If you're not likely to be editing at the same time then a wiki is good.
I've done the wiki thing, the passed document thing and the Google Docs thing.
The wiki thing has a low starting effort and lasts a pretty long time. At a certain size it does get to be a pain.
The passed document thing (writes, email, edit, email, etc) only works while one person is starting everything up. As soon as there are even minor edits then it sucks.
The Google Docs thing is fine until you have several docs and several editors or want to publish it online.
hth
This isn't programming related, but I've personally used Google Docs to write shared documents and found it easy to use.
I would suggest enabling Google Gears however, in the event that the Google servers go down momentarily or an internet connection isn't available.
For writing specs collaboratively, you could try Gingko.
It's a card-tree editor, which means it's a mix between index cards and an outliner, with real-time collaboration and full Markdown support (as well as basic LaTeX).
We are still missing several features (version history, comments, etc), but for some the benefits of having everything in a tree structure outweigh these drawbacks.
Writing specs with it is great, because you can create a card for each user story, and drill into it as much as you like (and organize them into categories if you'd like).
http://gingkoapp.com
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 5 years ago.
Improve this question
In my team we've got a great source control system and we have great specs. The problem I'd like to solve is how to keep the specs up-to-date with the code. Over time the specs tend to age and become out of date
The folks making the specs tend to dislike source control and the programmers tend to dislike sharepoint.
I'd love to hear what solutions others use? is there a happy middle somewhere?
Nope. There's no happy middle. They have different audiences and different purposes.
Here's what I've learned as an architect and spec writer: Specifications have little long-term value. Get over it.
The specs, while nice to get programming started, lose their value over time no matter what you do. The audience for the specification is a programmer who doesn't have much insight. Those programmers morph into deeply knowledgeable programmers who no longer need the specs.
Parts of the specification -- overviews in particular -- may have some long-term value.
If the rest of the spec had value, the programmers would keep them up to date.
What works well is to use comments embedded in the code and a tool to extract those comments and produce the current live documentation. Java does this with javadoc. Python does this with epydoc or Sphinx. C (and C++) use Doxygen. There are a lot of choices: http://en.wikipedia.org/wiki/Comparison_of_documentation_generators
The overviews should be taken out of the original specs and placed into the code.
A final document should be extracted. This document can replace the specifications by using the spec overviews and the code details.
When major overhauls are required, there will be new specifications. There may be a need to revisions to existing specifications. The jumping-off point is the auto-generated specification documents. The spec. authors can start with those and add/change/delete to their heart's content.
I think a non-Sharepoint wiki is good for keeping documentation up to date. Most non-technical people can understand how to use a wiki, and most programmers will be more than happy to use a good wiki. The wiki and documentation control systems in Sharepoint are clunky and frustrating to use, in my opinion.
Mediawiki is a good choice.
I really like wikis because they are by far the lowest pain to adopt and keep up. They give you automatic version control, and are usually very intuitive for everyone to use. A lot of companies will want to use Word, Excel, or other types of docs for this, but getting everything online and accessible from a common interface is key.
As much as possible the spec should be executable, via rspec, or doctest and similar frameworks. The spec of the code should be documented with unit tests and code that has well named methods and variables.
Then the spec documentation (preferably in a wiki) should give you the higher level overview of things - and that won't change much or get out of sync quickly.
Such an approach will certainly keep the spec and the code in sync and the tests will fail when they get out of sync.
That being said, on many projects the above is kind of pie-in-the-sky. In that case, S. Lott is right, get over it. They don't stay in sync. Look to the spec as the roadmap the developers were given, not a document of what they did.
If having a current spec is very important, then there should be specific time on the project allocated to write (or re-write) the spec after the code is written. Then it will be accurate (Until the code changes).
An alternative to all of this is to keep the spec and the code under source control and have check-ins reviewed to ensure that the spec changed along with the code. It will slow down the development process, but if it is really that important ...
One technique used to keep the documentation in sync with the code is literate programming. This keeps the code and the documentation in the same file and uses a preprocessor to generate the compilable code from the documentation. As far as I know this is one of the techniques Donald Knuth uses - and he's happy to pay people money if they find bugs in his code.
I don't know of any particularly good solution for precisely what you're describing; generally, the only solutions that I've seen that really keep this sort of stuff in sync are tools that generate documentation from the source code (doxygen, Javadoc).
I was wondering if there exists any open source frameworks that will help me include the following type of functionality to my website:
1) If I am viewing a particular product, I would like to see what other products may be interesting to me. This information may be deduced by calculating for example what other people in my region (or any other characteristic of my profile) bought in addition to the product that I am viewing. Kind of like what Amazon.com does.
2) Deduce relationships between people based on their profile, interaction with one another on the website (via commenting on one another´s posts for example), use of the website in terms of areas most navigated, products bought in common etc.
I am not looking for a open source website with this functionality, but something like an object model into which I can feed information about users and their use of the site including rules about relationships and then at a later point ask it questions described in (1) and (2) above.
Any pointers to white papers / general information about best approaches to do this, or any related links will really help too.
(I am the developer of Taste, which is now part of Apache Mahout)
1) You're really asking for two things here:
a) Recommend items I might like
b) Favor items that are similar to the thing I am currently looking at.
Indeed, Mahout Taste is all about answering a). Everything it does supports systems like this. Take a look at the documentation to get started, and ask any questions to mahout-user#apache.org.
For 1b) in particular, Mahout has two answers:
If you are only interested in what items are similar to the current item, you would be interested in the ItemSimilarity abstraction in Mahout (org.apache.mahout.cf.taste.similarity.ItemSimilarity) and its implementations, like PearsonCorrelationSimilarity. Based on a set of user-item ratings, this could tell you an estimated similarity between any two items. You'd then just pick the most similar items. In fact, look at the TopItems class in Mahout which can just figure this for you quickly.
But also, you can combine a) and b) by computing recommendations, then applying a Rescorer implementation which then favors items that are similar to the currently-viewed item.
2) Yes likewise, you would be interesting the UserSimilarity abstraction, implementations, etc. This would deduce similarities based on item ratings. Mahout however does not help you deduce these ratings by, say, looking at user behavior. This is domain-specific and up to you.
Sound confusing -- read the docs and feel free to follow up on mahout-user#apache.org where I can tell you more.
I am researching the same topic, as I'm working on a project to help people decide how to vote on California's complicated ballot measures. Here are some open-source collaborative filtering engines that I've found:
Vogoo (PHP)
acts_as_recommendable (Ruby on Rails)
Mahout (formerly Taste) (Java)
There's also a good overview of these engines here.
There are also the Duine framework and OpenSlopeOne.
But in my opinion, Mahout is still the best.
You can find a survey about Open Source Recommender Systems here:
http://girlincomputerscience.blogspot.com.br/2012/11/open-source-recommendation-systems.html
Hope it helps!
You can find a List of Recommender Systems here