Everytime you upload or upvote something, it gets saved to your LocalStorage for the site. Once something gets downvoted to zero, it disappear. When you go to the site, whatever is in your LocalStorage gets uploaded and upvoted again. So stories can come and go as users connect and disconnect, and only the most popular stories will always be visible on the site (since at least one connected user needs to have uploaded or upvoted a story for it to be visible).
Of course, there is still a server, that could decide to censor stories, modify text, but at least you can always check that what you have on YOUR machine is the data you wanted. you can always copy that data elsewhere easily for safe keeping (browser developer tools let you inspect your LocalStorage content).
I write and maintain a lot documentation, both open source and commercially. Quite a bit of the documentation I maintain is intended to be collaborative documentation. Over the past few years, through my own observations and insights from others (yes, this blog post is basically a rip-off of a smaller comment by Greg), I've come up with a theory on collaborative documentation, and I'm interested in feedback.
tl;dr: people don't seem to trust Wiki content, nor explore it. They're also more nervous about editing Wiki content. Files imply: this is officially part of the project, and people feel comfortable sending a PR
When talking about documentation, there are three groups to consider: the maintainers, the contributors, and the readers. The most obvious medium for collaborative documentation is a Wiki. Let's see how each group sees a Wiki:
Maintainers believe they're saying "feel free to make any changes you want, the Wiki is owned by the community." By doing that, they are generally hoping to greatly increase collaboration.
Contributors, however, seem to be intimidated by a Wiki. Most contributors do not feel completely confident in their ability to add correct content, adhere to standards, fit into the right outline, etc. So paradoxically, by making the medium as open as possible, the Wiki discourages contribution.*
Readers of documentation greatly appreciate well structured content, and want to be able to trust the accuracy of the content they're reading. Wikis do not inspire this confidence. Despite my previous comments about contributors, readers are (logically) concerned that Wiki content may have been written by someone uninformed, or may have fallen out of date.
By contrast, let's take a different model for documentation: Markdown files in a Github repository:
Maintainers have it easy: they maintain documentation together with their code. The documentation can be forked and merged just like the code itself.
Contributors- at least in my experience- seem to love this. I've gotten dozens (maybe even hundreds) of people sending minor to major pull requests to documentation I maintain on open source projects this way. Examples range from the simplest (inline API documentation) to the most theoretically most complex (the content for the Yesod book). Since our target audience is developers, and developers already know how to send pull requests, this just feels natural.
Readers trust content of the repository itself much more. It's more official, because it means someone with commit access to the project agreed that this should belong here.
This discussion came up for me again when I started thinking about writing a guide for the Haskell tool stack. I got halfway through writing this blog post two weeks ago, and decided to finish it when discussing with other stack maintainers why I decided to make this a file instead of another Wiki page. Their responses were good confirmation to this theory:
Ok, that makes a lot of sense to me. We might want to consider moving reference material to files (for example, the stack.yaml documentation). Another nice thing about that is that it means the docs follow the versions (so no more confusion about whether the stack.yaml page is for current master vs. latest release).
I can confirm this sentiment is buried in me somewhere, I've definitely felt this way (as a user/developer contributing little bits). On a more technical note, the workflow with editing the wiki doesn't offer up space for review - it is a done deal, there is no PR.
While Wikis still have their place (at the very least when collaborating with non-technical people), I'm quite happy with the file-as-a-collaborative-document workflow (that- I again admit- Greg introduced me to). My intended behavior moving forward is:
- Keep documentation in the same repo as the project
- Be liberal about who has commit access to repos
* I've seen a similar behavior with code itself: while many people (myself included in the past) are scared to give too many people commit access to a repository, my experience (following some advice from Edward Kmett) with giving access more often rather than less has never led to bad maintainer decisions. Very few people are actually malicious, and most will be cautious about breaking a project they love. (Thought experiment: how would you act if you were suddenly given commit access to a major open source project (GHC/Linux/etc)? I'm guessing you wouldn't go through making serious modifications without asking for your work to be reviewed.)
We prepared small set of haskell packages for openSUSE distribution. We now support GHC-7.10.2. + set of packages for Haskell Platform, with versions based on LTS Haskell. + Pandoc , XMonad, Xmobar
- openSUSE Tumbleweed is supported in official repository
- for openSUSE 13.1 and 13.2 are the newest versions in OBS
we now support x86, x86_64 , ppc32,ppc64 and ppc64le architecturessubmitted by mimi_vx
[link] [8 comments]
You can find the details of the position here.
In case you are interested and happen to be at ICFP, drop me a line.
So, here's my answer. Here's what I do and how I do it.
So, it depends on how and where you want to start this adventure, yes? The beauty of today is that there is so many resources freely available to let you work on them. The problem is that you're good at what you do already, so it'll be hard to move away from what you know already into the domain where it should be easy but it's actually really, really different and that difference can be frustrating: caveat coder.
Also, there are effete programmers out there that tell you how you should not code.
"Oh, Prolog's not pure and it's not functional. You can't do that."
I don't listen to what I can't do. When somebody says to me: "you can't do that," it really means they are saying: "I can't do that." And I'm not interested in listening to the whining of losers. What I'm interested in is delivering results by coding well. If you want to do that, I want to do that with you. If you want to tell me what I can't do, the door is over there, don't let it hit you on your way out of my life.
Sorry. Not sorry.
I host @1HaskellADay where I post a problem that you can solve in any language you want, but I post the problem, and the solution, in Haskell, every day, Monday through Friday. You can learn FP one day at a time that way, be it Haskell, Scala, Idris, whatever you'd like. You write a solution in Haskell, I retweet your solution so everybody can see you're a Haskell coder.
Also, there are contests on-line, some with money prizes (kaggle, right?), that you can take on in language X. You may or may not win, but you'll surely learn what you can do easily, and what comes hard in your language of choice.
The way I learn a language is I don't. Not in the traditional sense, that is, of learning a language's syntax and semantics. If I don't have a 'why' then the 'how' of a language is uninteresting to me.
So I make a 'why' to learn a language, then I learn it.
What I do is I have a real-world problem, and solve it in that language. That's how I learn a language, and yes, so I code wrongly, for a long time, but then I start to code better and better in that language, until I'm an expert in that language.
Reading any and everything on the fundamentals of that language, as I encounter them, help me a lot, too.
So, as you can see. I'm learning the 'languages' Neo4J and AWS right now (yes, I know, they aren't languages. Thanks). Lots of fun. I'm doing stuff obviously wrong, but the solutions I provide they need at work, and I'm the only one stepping up to the plate and swinging hard and fast enough to keep them funding these adventures in this tech.
Get that. They are paying me at work to learn stuff that I'm having a blast doing. Why?
Maybe it's because when the VP says, 'Hey, I got a problem here for ya,' I come running?
Here's something I do not do.
I DO NOT ASK: 'can I code in X?' because the answer is always: 'No.'
What I do, is code in X and then hand them a result that so wows them, they feed me the next impossible problem to solve, and I get to set the terms. It's like instead of 'doing my job,' I instead take ownership of the company and its problems, looking for the best solution for the company as its owner. And, like an owner, I say what I do and how I do it, because I know what's best for the company in these new waters we're exploring together in partnership.
Try it that way. Don't say 'we should do X' because that's what (in management's eyes) whiny little techies say. No, don't say anything. Just code it in X, deliver the solution, that you demo to the VP and then to the whole company, and get people coming up to you saying, 'Wow. Just wow. How the hell did you do that?'
No kidding: it takes a hell of a lot of courage to be a water-walker. It has for me, anyway, because the risk is there: that you'll fail. Fail hard. Because I have failed hard. But I choose that risk over drowning, doing what they tell me and how they tell me to do it, because I'm just employ number 89030 and my interview was this: "Do you know Java?" "Yes, I know Java." And, yay, I'm a Java programmer, just like everybody else, doing what everybody else does. Yay, so yay. So boring.
I've failed twice in my 25 years in this field, and wasn't for lack of trying. Twice.
Do you know how many times I have succeeded? I don't. I've lost count. I've saved three teens' lives and that was just in one month. Put a price on that, and that was because I stepped up to the plate and tried, when nobody else would or could. And my other successes, too, and the beauty of my successes is that the whole team won, we all got to keep working on really neat stuff that mattered and got company and customer attention.
And, bonus, "Hey, I've got a business and I need your help."
Three times so far.
Taking the risk leads to success. Success breeds success.
It starts with you, not asking, but just taking that risk, trying, a few times or right off the bat, and succeeding.
And that success, and the feeling you get from knowing you've done something, and you've done something.
They can't take that away from you.
I am a Haskell beginner who finds Haskell absolutely fascinating and have learned quite a bit of category theory to further my understanding of various concepts. I've learned a great deal and understand to a reasonable degree Monoids, Applicatives, Monads, and Comonads. Where should I direct my learning to have enough practical knowledge to code a Haskell project in an effective manner? It sort of seems like a never ending bucket list of things to learn to get proficient (I see terms like arrows, lens, other advanced functional constructs thrown all over the place and its a bit overwhelming). Assuming I have a relatively small, finite amount of time to learn each week, without a large theoretical background in abstract math, what portions of category theory are worth diving into to be able to code effectively in Haskell and what portions don't yield as much bang for buck?submitted by DPakeD
[link] [17 comments]
[ANN] dejafu-0.1.0.0: Overloadable primitives for testable, potentially non-deterministic, concurrency.
I am very pleased to announce the release of version 0.9.0.0 of my reactive-banana library on hackage. The API is essentially the same as before, but the implementation has been improved considerably: Dynamically switched events are now garbage collected!
This means that the library finally features all the ingredients that I consider necessary for a mature implementation of FRP:
- Continuous time semantics (sampling rate independence, deterministic union, …)
- Push-driven performance
- Dynamic event switching without time leaks
- Dynamic event switching with garbage collection
The banana is ripe! In celebration, I am going to drink a strawberry smoothie and toast Oliver Charles for his invaluable bug reports and Samuel Gélineau for tracking down a nasty bug in detail. Cheers!
While the library internals are now in a state that I consider very solid, the library is still not quite done yet. When introducing the API for dynamic event switching in version 0.7, I had the choice between two very different regions of the design space: An approach using a monad and an approach using phantom types. I had chosen the latter approach, mostly because the sodium FRP library had chosen to explore the former region in the design space, so we could cover more of the design space together this way. But over the years, people have sent me questions and comments, and it is apparent that the phantom type approach is too unwieldy for practical use. For the next version of reactive-banana, version number 1.0, I plan to radically change the API and switch to the monadic approach. While we’re at it, I also intend to remove simultaneous occurences in a single event. I will discuss these upcoming API changes more thoroughly in a subsequence blog post.
This is a hobby project of mine. The code is over at github.
I needed a fast way to import Discogs' data dumps (basically, 23GB of XML) into a PostgreSQL database.
I used postgresql-simple's semi-experimental (it can't handle errors for instance) COPY support for storing, hexpat and lens-simple for parsing and bytestring's Data.ByteString.Builder.Prim for escaping text for COPY (I'm pretty sure I can't use postgresql-simple's escaping since it's for INSERT, not COPY's text format, but feel free to prove me wrong).
I have to say it was pretty fun. I learned what contramap is and why it's useful while reading Aeson's internal Builder stuff for escaping ByteStrings (along with, well, how to use Builders), I had to chase a space leak and learned about laziness, and dropped cabal for stack.
The project structure is a mess, I know, I'm still a noob. But from a pragmatic point of view, it works! And it's fast!submitted by clrnd
[link] [2 comments]