Ask HN: What's your experience with "unlimited vacation"? - <AUTHOR> <comment><USER2> "Unlimited PTO" or "Vacation Freedom" or whatever cool term some people person wants to stick on it... it's really only as good as the company culture, boss and you make it. It's truly a combo of all three and people often forget that last one.

I've worked in several companies now that offer unlimited vacation. At first it was very strange to me and to be honest I didn't really utilize it properly at first. As I got older and wiser, I've been better at using it ... and also been at companies that were more vacation friendly.

If your boss is all for you taking the time off that you need, because your boss treats you like a fully grown adult capable of doing your work... you're gonna have a great time. If your company culture doesn't look at you like you have 3 heads for taking a half day off, you're probably good to go. If you remember that in order to enjoy the "benefit" of those vacations is to actually take the time off... then happiness is.

Most of the time when talking about unlimited PTO vs regular, people hammer on the point of "unlimited PTO = no money when you leave". For those people who want to work at a company for 366 days straight, get their 1yr cliff options, quit, take a month long vacation, get a new job...repeat. Then for them, they are totally correct, the pay out is good. However if you get smart about actually USING your vacation periodically, then who cares about the payout?

</comment><comment><USER3> IME it's a marketing scam, for 2 reasons (at least where I am - CA, USA):

1) Peer pressure from your boss(es) and coworkers who will tell you "now's not a good time to take time off" \- it's actually never a good time for you to take vacation, work will keep coming through the pipeline, deadlines will be scheduled, and you'll continue to feel pressured to not take a vacation, no matter how hard you've worked or how productive you've been. Has happened 3/3 times I've had a job w/ "unlimited PTO"

2) Employers use unlimited PTO policies as a way to not pay out PTO when you leave your job. With fixed PTO, employers have to pay you for that time if you don't use it when you leave. With an "unlimited PTO" policy, there is no longer any "leftover" time you get credited for. In conjunction with point 1 above, this ends up saving them money.

For CA: "Earned vacation time is considered wages. Vacation time is earned as work is performed. (Cal. Lab. Code § 227.3; Suastez v. Plastic Dress-Up Co., 647 P.2d 122, 128 (Cal. 1982).)"

PTO laws by state here: [http://ask.legalsolutions.thomsonreuters.info/cc-nto- vacatio...](http://ask.legalsolutions.thomsonreuters.info/cc-nto-vacation- rolling-pl)

</comment><comment><USER4> I had a job where we had our normal PTO, but at the same time, my immediate boss allowed us to take PTO without removing it from the official system. In this sort of arrangement you tend to respect the business. You don't want to abuse the system and ruin it for yourself or anyone else, but you also aren't getting screwed over by the lack of saved up PTO when you leave. It's strange but it was by far the best way of dealing with this that i've ever seen.

What ultimately occurred was when people went on a real vacation, they used their real PTO. for all the other life stuff like dr's appts and sick days and whatever, those just got ignored. this is how it should be. trust your employees people.

sorry it doesn't answer your question OP but hopefully any HR people reading this will see how they can modify the policy to help everyone.

</comment><comment><USER5> Never took a job with "unlimited vacation" but had interviews with a few of such companies. Right now, I get 4 weeks off with unlimited sick time.

So during interviews, I asked them about "unlimited" vacation policy and how many days they took off last year. It is almost always less than 20 days. When I asked them why they didn't take more days off and that I got 4 weeks of vacation plus a few days of sick time off. They usually make up excuses like it was unusually busy year, don't feel the need for more vacation, or it is still more than most people took off last year.

Or sometimes they are honest and say that they feel guilty asking for more time off, hard to get approval for 3rd week off, they rather have fixed number of vacation and not feel guilty about using all of it.

</comment><comment><USER6> I recently took a new role and talked to a couple of companies that offered "unlimited holidays".

After talking to them I came to the conclusion this is something that looks nice on paper but is actually doing you a disfavour. Because if you take up on the offer and take substantially more holidays then the rest of the team you'll look bad. And if you take fewer holidays you are losing your rights.

In my opinion, if a company wants to be generous, offer generous fixed holidays so I can take them without feeling guilty.

(Funnily enough, those companies were always against remote work. For me that is contradictory, you don't want me to work from home but be off instead?)

</comment><comment><USER7> We have it at my dayjob employer. It works out OK. The way my manager put it to me, is that "unlimited vacation" just means that "nobody is counting how many days you take". Basically, as long as your manager approves your request, you're good. And I've never had a request declined.

I don't count my off days either, but I usually take 3 weeks (all total, including company vacation days) over the Christmas Holiday season, a week (again, including vacation days) over Thanksgiving, a week over the 4th of July week, and one or two random sick days / mental health days / whatever, throughout the year.

Note that this is a big international megacorp, not a startup, so YMMV.

</comment><comment><USER8> Definitely seems like sort of a scam to me... I mean why wouldn't I just use all the vacation time? The company would use all of my hours working if they could...

I'd rather things be straight forward to be honest.

</comment><comment><USER9> I ended up taking less, was just looking at this today actually.</comment>


Congress Just Buying People Cars Now - <AUTHOR> http://www.economist.com/blogs/freeexchange/2009/07/congress_just_buying_people_ca.cfm

<comment><USER2> Can I have a $4500 voucher for a new bicycle? It uses no fossil fuel at all. (I estimate that an 18-pound bike will cause me to consume one less banana per week, compared to my current 21-pound bike. This will save hundreds of bananas per decade.)

<comment><USER3> I wasn't aware that banana consumption was a problem or that America depends on a healthy bike industry to thrive. News to me!

<comment><USER2> I wasn't aware that having a slightly-old car was a problem.

<comment><USER4> It isn't a problem. You car is probably perfectly fine and may get great gas mileage. The problem is that you are not consuming. Bad American!

</comment></comment></comment></comment><comment><USER5> Cars? People still buy those things?

I wonder how much non-drivers' taxpayer money goes to subsidizing others' choices of transportation like this...

<comment><USER6> Easy to say that if you live in a densely populated city with good public transit. Not everyone has the luxury of living close to public transportation or within walking distance of all necessary services they need.

<comment><USER2> It is not a luxury, it is a conscious decision that many people make sacrifices to obtain.

<comment><USER7> True, but what about people who live in small towns or rural areas. I'm not talking about suburbia--many of those people made conscious decisions to live far away from their work and amenities. Or do we just tell those people they really need to make a sacrifice and move to the city?

I appreciate this perspective, though. I've ridden my bike to work for the last eight years. My family lives in the city (I live not far from where I grew up) and we use public transportation. And I agree with the Economist-- this program is really about getting people to buy new cars.

 _Cars? People still buy those things?_

Yes. Why not? They're a tool, just like everything else. My family really enjoys traveling, so we (four of us) own one car. More often than not, it's parked in front of our house. We walk, bike, and bus ourselves around when we can. But it's also nice to be able to leave the city on the weekend and go camping and climbing. Or visit family. Acting as if you are on a higher moral plain because you can't comprehend why people still buy cars doesn't do much to advance the conversation and convince people to rethink some of their lifestyle choices.

That said, as I mentioned, I think this subsidy is a terrible idea.

<comment><USER2> A car doesn't sound like a very good investment if you never use it. Better to use a car sharing service... although I guess those don't exist in the suburbs.

<comment><USER8> There's a very good reason for that.. it would cost too much to have a car available everywhere it would need to be.

</comment></comment></comment></comment></comment></comment><comment><USER9> What we have here is a wasted opportunity.

This program could have required a 10 mpg improvement and could have been set up to require at least 28 mpg on the new vehicle, by using two different numbers, and it would still be very successful and have made the US less dependent on foreign oil imports. Oops.

Too much influence have the firms that make "campaign contributions".

<comment><USER3> This isn't about the environment, it's about the economy. The enviro-aspects are simply a bonus and helped get this stimulus plan passed. If it was too restrictive less people would have qualified thereby killing any economic benefit.

<comment><USER9> That's all good, but if you read carefully you'll see I made no mention of the environment in my post, which was focused on the national security benefits to being less reliant on foreign oil.

</comment></comment></comment><comment><USER4> This program is about keeping consumerism alive to benefit the economy, not about fuel efficiency, The idea of trading in clunkers for fuel efficient vehicles is a thin veil to the real goal of getting people to buy things from an industry who lobbied the government to give them a handout. Instead of Goldman Sachs and Bank of America, the robbers this time are car dealers.

</comment><comment><USER10> I can't imagine it does _any_ good for the environment, at least not until >five years from now. Producing a car isn't exactly easy on the environment, and requiring people to buy _new_ cars isn't going to help.

<comment><USER7> Producing _anything_ isn't easy on the environment.

<comment><USER11> How about locally hand-built wooden furniture from sustainably managed forest - it sequesters carbon and provides often beautiful goods is relatively labour intensive (good for employment figures) and preserves traditional skills. Well managed forest will preserve the natural living environment of many species.

Bonus points if the carpenter eats a low animal-protein diet.

<comment><USER7> Likely will still require some metal production for tools.

I'm not advocating that we don't produce things--I just think we often overlook the costs of production when we look at environmental factors.

</comment></comment></comment></comment><comment><USER12> Congress... *siiiiiiiigh</comment>


Ask HN: Webspace/server tips for startups - <AUTHOR>

Hi! Are there any resources or tips on choosing a path regarding webserver/space for launching a webapp? As I see it, buy a domain and then either rent webspace or buy a server and stash it under the bed. Since users will be able to upload content and I pretty much need a lot of space I'm guessing buying my own server is the way to go.<p>Are there any cheaper alternatives? And on the other side, what would be the fastest way to launch? (assuming there is a ready webapp where deployment for launch is next step) <comment><USER2> I certainly hope people that are buying their own servers aren't stashing them under their beds.

You should really consider VPS if your needs out way shared services, which I would seriously question if you are brand new. If VPS in all its forms, including slicehost or linode is still holding you back (I'm not sure there are many cases of this being true), collocation would be the way to go.

Hosting your own data centre makes very little sense these days given the options available.

</comment><comment><USER3> I'd look into Slicehost for a web server, and using it in conjunction with Amazon S3 if you're planning on serving a lot of files.</comment>


Psilocybin for treatment-resistant depression - <AUTHOR> http://www3.imperial.ac.uk/newsandeventspggrp/imperialcollege/newssummary/news_17-5-2016-10-42-14 <comment><USER2> From May 2016</comment>


DC Proof -- a free program to help you learn to do proofs - <AUTHOR> http://www.dcproof.com/ <comment><USER2> I'm glad to see more math software out there. But we shouldn't think of "proofs" of some totally unusual sub-part of math.

A math professor told me once, "A good proof is just an essay that can convince a skeptical mathematician." In the U.S. there is this bastardized combination of geometry with "two column proofs" that gives everyone the wrong idea. Better are problems like, "Spot the flaw in this reasoning".

The concept of proofs should be a way of explaining that to a mathematician, truth is black and white. It's different than the concept of truth in the liberal arts or even science. Turning it into abstract logic puzzles is cool but it misses the best point.</comment>


Ruby Frameworks? Which one? Bye bye Rails. - <AUTHOR> http://www.slideshare.net/zhesto/padrino-the-godfather-of-sinatra

<comment><USER2> I empathize with the comments from the folks who are already heavily invested in Rails. It's so easy to "just throw the whole stack at a problem" or "kill a fly with a shotgun." This is always the way, and it's why new ideas rarely displace the old ones directly. Instead, they have to appeal to a younger, nascent "market" that are not attached to the old product.

Padrino's best bet is to appeal to a younger, fresher group of programmers who haven't spent years learning Rails, just as Rails appealed to a younger, fresh generation of programmers who hadn't spent years learning Struts. Those folks will find applications for it where Rails actually gets in their way. As they reinvent parts os Rails, they'll invent new things that fit their model domain better than Rails does.

I'd bet that if Padrino becomes successful, it will do so with ORMs and other gems that aren't popular on Rails because they haven't been invented yet.

If you are resistant to adopting a new framework and having to reinvent a bunch of stuff, congratulations. You may be an early adopter or hacker in other areas of your profession, but as far as web development goes, you're a conservative.

<comment><USER3> This is a weirdly emotional appeal that ignores the fact that Rails is not Struts, is nothing like Struts, isn't standing still, was more or less rewritten not very long ago by assimilating its best competitor, and that the next ORM or gem that isn't popular today on Rails is very likely to be bootstrapped and implemented in the context of Rails --- unless its key distinguishing value is "a not-Rails replacement for something Rails already does", which many people on this thread are pointing out is a seductive trap.

Rails is good. For an alternative to be compelling, it probably needs to be more than just "different"; it needs to be better. What I see people saying here is, yes, "stripped down" is different, but in practice that difference turns out not to be better. The parts of Rails you really can't get around using tend to be parts you're going to need in a Sinatra or Padrino app, and rewriting them just for the sake of it isn't a win.

<comment><USER4> I disagree. The main reason I dislike Rails is that it is too complicated. When working with it every day, I regularly come across issues with it that require that I delve into the source code. More often than not that is a depressing venture.

I would love something more simple, that operated with less magic, and had code that was easier to understand. I'm not sure if Padrino is the answer, but it certainly merits a second look.

<comment><USER3> When's the last time you had to dive into the Rails source code? The only bits of Rails I'm consistently familiar with at the source level are the code that maps HTTP parameters to the "params" hash and into AR model attributes, and the session cookie stuff --- and those are professional interests, not "I couldn't figure out how to use it" things.

I'm asking seriously, because I spend about 20% of my work time writing Rails code for a bunch of different Rails apps, and --- at least since Rails 3 --- I never have to do this. And I'm a C programmer, so "diving into the code to figure shit out" is a first instinct for me too.

<comment><USER4> About a week ago I had a problem with after_commit callbacks not being called. It turns out (after diving into the AR source) that they indiscriminately swallow errors from after_commit callbacks. If you're testing a newly-created callback it is difficult to determine whether it's actually been called or merely just raised an error.

I couldn't have figured that out without reading the source- it's not documented. From the developer level that behavior is indistinguishable from magic, and the callback code in AR tries to act like magic as well. It's extremely difficult to follow, let alone understand.

<comment><USER5> "The after_commit and after_rollback callbacks are guaranteed to be called for all models created, updated, or destroyed within a transaction block. If any exceptions are raised within one of these callbacks, they will be ignored so that they don't interfere with the other callbacks. As such, if your callback code could raise an exception, you'll need to rescue it and handle it appropriately within the callback."

[http://guides.rubyonrails.org/active_record_validations_call...](http://guides.rubyonrails.org/active_record_validations_callbacks.html)

<comment><USER6> "The whole callback chain is wrapped in a transaction. If any before callback method returns exactly false or raises an exception, the execution chain gets halted and a ROLLBACK is issued; after callbacks can only accomplish that by raising an exception."

― [http://guides.rubyonrails.org/active_record_validations_call...](http://guides.rubyonrails.org/active_record_validations_callbacks.html#halting- execution)

<comment><USER5> I'm not sure what your point is. He was talking about after_commit callbacks. Your quote is about the callbacks during a transaction, not after it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> As someone that has been writing production Rails and Sinatra apps for years, I have to recommend against using Padrino. Rails scales up and down pretty well, and I don't really see a need for Sinatra in anything but very small or single-purpose apps.

You can even write a Sinatra clone in very little code on top of Rails: [http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on- rai...](http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rails-3/)

If you already know Rails, there is very little reason to build a substantial app in anything "smaller". The reality is that for any moderately-sized app, you will end up using many of the parts of Rails that you think are unnecessary in the beginning. Especially as your app grows.

I tried using Padrino for an app a year ago, and while the framework has probably matured since then, I moved back to Rails fairly quickly due do a lack of polish/documentation/community/benefit other than being different.

There is a common tendency to find a part of a framework that doesn't work exactly the way you want, and in turn throw the entire framework out and seek out or write something new. I still prefer the way Merb and Sinatra handle responses, where the controller action return value is the response sent to the client. But the benefits that Rails provides so outweigh many of these kind of preferences that it's usually best to just embrace the way the framework works and move on to actually building an app that does something.

It's also short sighted to discount how valuable the wealth of existing documentation and extentions exist for an established framework such as Rails.

The presentation makes it sounds as though by using Rails you have to use SASS and Coffeescript. This is not true, you can easily use plain JavaScript and CSS if you want.

The majority of developers will be more productive in Rails.

<comment><USER8> Sinatra has a great use case in Service Oriented Architecture and APIs. One Rails app supported by 4-5 Sinatra/Rack apps.

</comment></comment><comment><USER9> I love the idea. No unnecessary crud, simple, clean. What's not to love?

It's the practice that I'm having problems with. Medium-large projects have tendency to actually use big part of the bag of tricks Rails provides.

But smaller ones, where Padrino should shine... it doesn't. When running one or two server processes, I don't care that it consumes 30MB more RAM than it should, or renders take two milliseconds longer than they could. If I did, I would use something else instead of ruby. However, when I actually try to use that one neat feature, only to remember that it's Rails-specific, or find out that this gem I'm not familiar with has documentation only as far as Rails- integration is concerned, that's a real and measurable dip in my productivity.

These small projects are usually weekend hacks where I would rather not spend time writing boilerplate I know can be replaced by one line by that other framework, or digging through sources of a library before I can start using it. It gets very tempting to just throw in the whole Rails stack and focus on the interesting bits.

These problems could be alleviated by more widespread use of other Ruby web frameworks (and I do wish they gain more traction!). But right now, my laziness keeps me from 'being part of the solution'.

</comment><comment><USER10> This reminds me of Flask for Python (nb. although more is built in to Padrino, most of the functionality for Flask is provided by plugins). I've recently started using Flask for new projects in favor of Django. I feel that most of the libraries I use are framework agnostic, stuff like ORM (SqlAlchemy), PDF generation, redis/mongodb adapters etc, so being able to pick what fits and leave the cruft out is great.

But besides that, I feel that in recent times development is moving much more to the client - and client code like Javascript/CoffeeScript, Java for Android and Objective C, is getting much bigger at the expense of server side code. This is recently evidenced by the new 37signals Basecamp Next app which is 50/50 CoffeeScript/Ruby.

So the server side programming is on track to becoming "just" a API endpoint for all these different technologies and I think micro frameworks like Flask and Padrino are very well suited for that.

<comment><USER11> Could you go more in detail with your experience with Flask? I am new to web development and I am developing a landing page in Flask. I tried to use Django or Rails in the past but I just hated not being able to understand what I was doing. Flask is really, really, straightforward, I rolled out my own authorization plugin as a decorator and it feels good to be so close to the application. But I keep thinking if I should move to RoR in case my landing page succeeds and I will have to build the real application. Mostly, I am concerned about hosting and scaling...

</comment></comment><comment><USER12> Ok seriously, why the flamebait title? This deck is about padrino, yet it's no where in the title. We should be enticing discussion not argument in our titles. Also, now I'm not going to be able to find this post in a search. I'm going to have to search through all the negative posts about rails to find it instead of just searching for padrino.

If HN had downvotes on submissions, this is one of the rare cases I would find it useful as 'flag' doesn't seem to really qualify.

</comment><comment><USER13> Padrino is the perfect framework for Djangonauts who want to learn a ruby web framework whilst also learning the language, which was my case 1 year ago. Especially those who don't like the "rails way".

It has most everything we love about Django: admin site, mountable apps (which I consider actually better than Django's), speed (it is as fast as Django in my benchmarks) plus a sane and flexible routing sytem, generators, localization, full support for various subframeworks and a much, much better configuration system (no global settings file!).

It is everything I wish Django was, but in Ruby.

</comment><comment><USER14> Would like to hear from people who have taken a user-facing Padrino/Sinatra app all the way through production and into maintenance.

I have a few tiny services and extremely specific apps running on Sinatra, but any time I've needed to expose any kind of richness to the user I've ended up reimplementing in Rails as I kept reaching for things in ActiveSupport / ActionView etc.

At some point I notice myself essentially recreating Rails' structure in my 'lightweight' app and think 'why don't I just use Rails?'.

<comment><USER15> I do all my production app in sinatra/padrino. I like the fact that I can do pretty much every app from a simple api to a full webapp with the same stack without changing the framework.

I never miss ActionView, but sometimes include parts or all of ActiveSupport, so I don't miss that either. I love the simplicity of the sinatra stack and I've never been much of a rails fan (too tightly integrated for my taste, the 1.x and to a lesser extend the 2.x version were too magic sometimes etc.) Most middleware is rack-based anyways.

For me the winner is that a padrino app is a full, mountable rack application so I can mount any padrino application anywhere inside any other application. I can actually implement complete components as a padrino app and mount and reuse them anywhere I wish. (The padrino admin works that way)

<comment><USER3> Can you be more specific? I'm curious. What are the bits of ActionView that get in your way? I ask because to me, as far as views go, both Rails and Sinatra are just hosting systems for Haml. If anything, it's Sinatra that got in my way (it doesn't have explicit partial support, so there were minor things I had to tweak). I can't think of many "features" of ActionView I used.

I generally agree that Sinatra was an easier sell in the Rails 1.x and 2.x era, before Rails ate Merb.

<comment><USER15> Sorry, I didn't want to imply that ActionView gets in my way - I just don't miss it. Padrino uses the excellent Tilt templating library and it loads pretty much all template engines I could wish for and it does add explicit partial support to sinatra. That's about all I could want from ActionView. I don't like or use form-builders for instance, I prefer not to use the js/ajax- helpers etc.

I guess it boils down to a matter of preference: I prefer my stack to be built from the ground up on a solid foundation by adding pieces I want and need in my app - and that's what I can do with padrino. If I'm writing a pure API it's sinatra plus the padrino router, tilt, maybe an orm and that's about it. If I need something more comprehensive I can add components on top of that that add the required functionality (render-helpers such as partials etc.)

<comment><USER3> Yeah, I haven't used the form helpers in ages, I just write normal jQ Javascript code and pretend Rails doesn't have "ajax" support, and I hardcode my links instead of using link_to. You're right, there's a bunch of stuff ActionView does that I've had to opt out of using.

</comment></comment></comment></comment></comment><comment><USER16> Padrino is really nice web framework for Ruby. I have used it for experimental projects.

My work was using latest Padrino framework at work, but extremely unhappy with the its performance (slow response). We had ported the app to Rails 3.1 for better performance. (We will upgrade it to 3.2 soon)

In fact, I think Padrino is pretty ideal for personal and small apps. Not really ideal for medium to large apps.

Just my opinion and experience.

<comment><AUTHOR> Warn: is opinionated

Btw I switched lots of projects from rails to padrino due to the slow performances of rails.

I built a small test suite where you can find that Padrino is upto 4x faster than rails.

Check it out: <https://github.com/DAddYE/web-frameworks-benchmark>

Feel free to show me that Im wrong.

<comment><USER16> I am not against the Padrino web framework. I still like it. :-)

So your benchmark only have tested against the small "Hello World" app. Maybe that's why I suggested that Padrino framework is pretty ideal for small/personal/API projects for fastest responses.

Have you tried benchmarking your one of biggest padrino apps?

<comment><AUTHOR> That's not 100% true, there are more than `hello world` benchs.

Check it out here: [https://github.com/DAddYE/web-frameworks- benchmark/tree/more...](https://github.com/DAddYE/web-frameworks- benchmark/tree/more_advanced)

Yep, speed is 4-6x faster, but most important for me is memory usage is much much less.

On every Rails project I need to use monit/god to stop/start when for xx cycles memory is > 100mb or so. Without that a rails project can sucks 1-2gb of ram.

Isn't quite normal to my standards, in fact generally Padrino doesn't need more than 70mb. But here a lot of work must to be do.

<comment><USER16> Sorry if I have to ask, what part is not 100% true? You mean that padrino app can be still faster with large app?

You said there are more than "Hello World" benchmarks? I looked at the link that you provided and then looked at this source code of the Padrino app and its still "Hello World":

[https://github.com/DAddYE/web-frameworks- benchmark/blob/more...](https://github.com/DAddYE/web-frameworks- benchmark/blob/more_advanced/padrino/app/controllers/main.rb)

I expected to see something more than just Hello World app.

I am trying to see why you are suggesting me that Padrino is better than Rails. :-) Sounds like you are completely against Rails. Maybe I am wrong.

<comment><AUTHOR> It's quite complicated make a full featured app for all webframeworks, btw look at here: [https://github.com/DAddYE/web-frameworks- benchmark/blob/more...](https://github.com/DAddYE/web-frameworks- benchmark/blob/more_advanced/padrino/app/controllers/main.rb#L7)

Which is: [https://github.com/DAddYE/web-frameworks- benchmark/blob/more...](https://github.com/DAddYE/web-frameworks- benchmark/blob/more_advanced/padrino/app/views/index.haml)

With a layout: [https://github.com/DAddYE/web-frameworks- benchmark/blob/more...](https://github.com/DAddYE/web-frameworks- benchmark/blob/more_advanced/padrino/app/views/layouts/application.haml)

Not a very very complex use case but a bit more than a `hello world` app.

I love Rails, Im using i.e. ActiveRecord in 90% of my projects. Beside that I ported 162 apps over Padrino not because I've free time to spend but because I need decent performances (without kongfu with mem/redis caching) with less memory usage.

Try to browse rails (minus ActiveRecord) source code and padrino source code to understand what I mean.

</comment></comment></comment></comment></comment></comment><comment><USER17> Thanks but no thanks. Having just become a productive Rails programmer and grasped a lot of complexities, use cases and diversity of the framework, I'd rather use the shotgun that Rails is to kill any fly that stands in my way.

As long as the fly is dead, Rails did its job.

<comment><USER18> I can see where you are coming from, but ruling something out because another thing is doing it's job (in your opinion) is parochial. Unless you try new things out, you can never improve your existing workflow. You don't know what you don't know unless you explore.

<comment><USER17> Even though I agree with you in trying new things out, I think that never settling with an established tool is pointless. We are trying to get things done here.

My point is, I like trying new things, but I prefer to stick with tested and supported tools when working in a job, and leaving these new things to personal projects or hobbies.

Rails has not only a huge community, but a huge support of third party libraries that while they may not be the best performance-wise, they allow you to accomplish the project's goals.

</comment></comment></comment><comment><USER19> Yehuda Katz made a good point in this episode of ruby rogues <http://bit.ly/w7PJ0o> about how he uses rails even for small projects.

I use rails for everything, there is so much going on for you behind in the scenes in the way of security and configuration that it doesn't make sense to go back and roll your own on a minimal framework.

</comment><comment><USER20> As someone that's just crossed a year or Ruby/Rails learning, having scaled the majority of the now massively steep learning curve, I'll stick with the complexity that is Rails.

<comment><USER21> Ah the old sunk cost fallacy.

<comment><USER22> I'm not sure that's 100% accurate.

"sunk costs are retrospective (past) costs that have already been incurred and cannot be recovered", says Wikipedia. However, investment in Rails _can_ be "recovered", because it's a useful, marketable skill. Switching to something else will incur costs as well, so the benefits would need to be both high and certain to really make it a 'sunk cost fallacy', no?

<comment><USER21> > _I'm not sure that's 100% accurate_

It is. You're conflating several different notions. A sunk cost fallacy is the idea that because you've invested a certain amount of resources (time, in this case) in a particular approach, it would be foolish to switch because all the resources you've already expended would be "wasted."

<comment><USER23> > A sunk cost fallacy is the idea that because you've invested a certain > amount of resources (time, in this case) in a particular approach, it would > be foolish to switch because all the resources you've already expended would > be "wasted."

No, you're using the wrong word here. It isn't a sunk cost when you've _invested_ resources (i.e. can recover value from those resources in the future), it's when you've _spent_ (i.e. cannot recover value from the resources) resources.

The knowledge gained from learning Rails is obviously recoverable, and can be directly applied to future work. Throwing that away is not a sunk cost issue.

<comment><USER21> I stand corrected then. In my defense, however, I was talking about the time invested being a sunk cost, as the time is not recoverable -- and that's what the person I was responding to mentioned. The time.

</comment></comment></comment></comment></comment></comment><comment><USER24> Padrino is great for small apps but for medium to big projects I much prefer go the rails way and remove the parts I don't need.

You can remove the big rails modules if you don't need them (activesupport, activemailer, activerecord,. ..) but also the rack middlewares.

</comment><comment><USER25> Not sure why the author of the slides presents rails as a confusing mess. If you don't like the asset pipeline then don't use it. If you don't like the scaffolds then don't generate it. If you don't like active record, then don't use it.

I love the fact that these new frameworks are popping up, but why try to pull down rails in the process? If this addressed legitimate issues rails has, then I would not have a problem, but what's presented seems superficial.

I would love to know how Padrino lives with mongodb. Will the admin generator work with mongomapper or mongoid?

<comment><USER3> The asset pipeline you can easy do without. I've forgotten Rails even did Scaffolds. But even though AR is "pluggable", you're working against the grain in Rails if you don't use it.

<comment><USER26> I mostly disagree - nowadays it isn't AR that is essential ime. AM on the other hand is utterly essential and I end up implementing parts of it on almost every nonAR-model to get the nice interaction with AS.

</comment></comment></comment><comment><USER27> I definitely love Sinatra, and I'm impressed by the admin interface, but it looks like there's no support for DataMapper as an ORM.

I also wonder if this is just turning Sinatra into Rails. I think for the now I prefer to just build a Sinatra app and add gems and plugins as I need them.

<comment><USER28> Padrino supports the following ORMs out of the box: mongoid, activerecord, datamapper, couchrest, mongomatic, ohm, ripple, sequel. Take a look here: <http://www.padrinorb.com/guides/generators>

Padrino is just a Sinatra app with a very basic skeleton and some added functionality. Almost all the pieces are modular and doesn't have many requirements from the start.

<comment><USER29> On small addition: Padrino is also a Layer that stitches multiple Padrino Apps together, which is the true shiny feature.

</comment></comment></comment><comment><USER30> I'm sure Padrino has a niche in the Ruby community that it will appeal to, but I wish it brought more to the table than just being smaller than Rails and more full featured than Sinatra. If, say, it was engineered to be completely asynchronous, like node, that would be killer.

Its nice and I can see myself using it in very specific instances, but it doesn't feel like the Rails killer that the post title claims it is, but that's just me

</comment><comment><USER31> The only thing I see wrong with this is lack of coffeescript. I love coffeescript like bill clinton loved getting dome in the oval office, and if anything is without it, i will either cry, build support in myself, or both (at the same time?)

Anyway the point of this comment is please give us coffee! It looks like padrino has everything else covered and I really like the idea.

<comment><USER32> Coffeescript was mentioned in the slide, but why does the framework have to support CoffeeScript?

Theres plenty of ruby libraries like Guard to autocompile CS files or you could just us the built in CLI.

</comment></comment><comment><USER33> I believe the problem everybody trying to solve is that Rails is poorly suited to build RESTful APIs. If you love Rails and still want that, mount something like Grape (<http://github.com/intridea/grape>) inside your Rails app.

</comment><comment><USER34> I love Padrino so much that I started to write a book about it and my experience in developing an app with it <https://github.com/matthias- guenther/padrino-book>.

</comment><comment><USER35> 100x this. I hope Padrino picks up more steam and people it give it more love. It absolutely kicks ass and I would choose it over Rails everytime now.

Now, if someone would write Padrino with Python, I'd be one really happy camper!

</comment><comment> johnx123-up Looks like a Xitrum (Scala web framework) to me.</comment>


LA's Proposed Parking Signs - <AUTHOR> http://www.wired.com/2015/04/las-proposed-parking-signs-brilliantly-simple/?mbid=social_fb <comment><USER2> So much armchair quarterbacking in this thread. As a long time LA resident, these signs are a huge improvement over the current system of just adding multiple signs on the same pole. Many times I have to spend 5 minutes calculating whether or not you can park, and for how long. Here's a perfect example, and not unusual to see. [https://i.imgur.com/wyQsMTv.jpg](https://i.imgur.com/wyQsMTv.jpg) I can't wait for these new signs. "Perfect is the enemy of good."

<comment><USER3> Advantages of new signs \- consolidates parking restrictions in one easy to read graphic

Advantages of old signs \- can easily swap out restrictions by adding or removing signs

IMO it's not very difficult once you get used to it. Remember that the default is "parking is always OK" and add restrictions as you read top to bottom. Of course, each municipality may have its own "default" rules. The City of Los Angeles can tow you after 72 hours on the same street, and Pasadena has no parking 2-6am every day.

<comment><USER4> Regarding "easily swap out" -

In theory, swapping out restrictions should be a matter of checking some boxes on a web form or something, which would generate an appropriate image and send it to a printer, with - based on a quick Google - at most a few days' turnaround time, for (possibly well) below $100 per sign.

In practice, their process will probably be less efficient :)

</comment></comment></comment><comment><USER5> >Husting thought Sylianteng's design was a good concept to run with (Sylianteng wasn't paid for the project)

Wow. That's a shame, to say the least, unless she chose specifically to do this out of charity.

<comment><USER6> As far as I remember she ran a guerilla campaign, posting these signs all over the city. My understanding is she did it for the betterment of the town and possibly her portfolio.

</comment></comment><comment><USER7> The new signs are a better way to display a complicated schedule, but have they ever considered just simplifying the rules?

<comment><USER8> The problem with simpler rules is that it would basically be "No Parking, Anytime".

Often, the reason parking is prohibited during certain times is to open the lane up for rush-hour. If the rule had to be simplified, I think traffic decongestion would win over parking availability. Now imagine that same stretch of road gets sweeped every Tuesday at 2PM. The simplest rule to cover these situations—and still allow parking at all—has to somehow be communicated.

I don't care too much for the signs in the linked article, but I hate even more the existing signs that are all hodge-podgy. At least these signs standardize the information somewhat, so even if they are complicated to read, once you get used to them you'll be able to grok it at a glance.

</comment></comment><comment><USER9> How about an LED sign that just says "YES" or "NO"?

Edit: I guess energy would be a concern though :(

<comment><USER10> There is more information you'd have to communicate. Like how long I can leave my car in this spot before I have to move it.

<comment><USER11> It could be conveyed: "no parking until 2PM" or "parking until 5PM" or "parking for 15 minutes."

We'll have self driving cars before intelligent city street signs, then just let the cars figure out where they can park.

<comment><USER12> And then it becomes "No parking until 2pm unless you have a green permit, in which case you can park until 5pm. Except if that green permit has a blue diamond in the corner, which means you can't park here for more than three hours".

<comment><USER9> None of the signs I see on the webpage have those conditions, though.

</comment></comment></comment></comment></comment><comment><USER13> What do the sections that are green but have no (P) icon or time limit? Unlimited parking? The legend doesn't say.

It's also interesting to note that the section heights are not proportional; they range from 1 hour per unit during morning rush to 7 hours for mid-day. At first glance, it makes it seem parking is prohibited for nearly half the day during the work week, while in actuality it's just 4 hours.

</comment><comment><USER14> There's no way to indicate a 2hour street cleaning day on any of these signs. What's the most common street sign in SF/LA?

<comment><USER8> That day would get its own column. Look at the 4-Column Sign example in the article.

EDIT: I just realized sweeping isn't always a weekly thing. So yeah, there would still have to be another sign for that.

</comment></comment><comment><USER15> Here's a rather lengthy discussion of a similar redesign that began in LA:

[https://news.ycombinator.com/item?id=8923196](https://news.ycombinator.com/item?id=8923196)

<comment><USER16> This one is just an update of that one.

The original designer, Nikki Sylianteng, is cited in the Wired article.

</comment></comment><comment><USER17> Ugh, that looks overly complex especially if you want to read it before parking (or at least getting out of your car). Solar powered LEDs are really cheap; we actually have a bunch of lights around my way that are entirely run off of solar with batteries for night. Why can't the schedule be programmed and a crude digital sign display where you can park and for how long? Maybe say loading and unloading only at times?

I have a hard enough time explaining to users how to do simply things on a computer or hell even read directions; this seems like a pain to me.

<comment><USER18> No fallback (battery failure, etc) and more expensive.

<comment><USER17> They can hook them into the power grid for fallback if necessary but that doesn't really matter; simple metal signs also can have issues (spray paint, hit by car, stickers, etc) and I don't see anyone saying we shouldn't do those as they don't have a fallback.

Sure they're more expensive but solar is pretty cheap and it will allow them to modify and adapt to changing parking / driving patterns preventing more print runs of the signs in the future and possibly optimizing. Seems like a good way to spend money to me at least compared to a lot of other, more wasteful uses of tax money.

<comment><USER18> The issues you list for metal signs apply to electronic signs too, meaning they have even more potential problems.

Wiring them all would be a significant expense for councils.

I'd bet that reissuing metal signs is still going to be far more efficient. I'd be looking at ways to simplify use of the streets first. Sometimes low- tech solutions work best.

</comment></comment></comment></comment><comment><USER19> I first thought based on the shape of the first sign this was an app. Some city should make an app that gives this info based on your location.

<comment><USER20> The signs have bluetooth beacons for this purpose, though i havn't heard of an app for them yet.

</comment></comment><comment><USER21> I'll just use red-green colorblindness as an excuse to park any time.

<comment><USER22> You haven't read the article. The signs should work for color blind people too because of the stripes.

</comment></comment><comment><USER23> Are there any examples of how they're going to handle permits, holidays, exemptions, etc?

<comment><USER2> Temporary signage, just like they do today. Permits are already addressed.

<comment><USER23> Sorry, let me rephrase. Some parts of the city say things like No Parking unless with permit (for residents of the street). Or, what about 2 Hr parking unless Sunday or Holiday? Or what about 8-10AM street sweeping every other Monday. I feel like the new design doesn't solve for this.

</comment></comment></comment><comment><USER24> Isn't too small to read from a distance?

<comment><USER25> Doesn't matter. The rules for parking spaces in LA are usually complicated enough that you have to stop to read them anyway.

<comment><USER26> But not from 10 feet away like these ones.

Current signs are legible 50 feet or further - and more important legible while you're still in your car.

</comment></comment></comment><comment><USER27> there's no indication for street cleaning for "first Monday/Anyday of the month".

</comment><comment><USER28> Two sample takes from a smart LA blog:

Against: [http://www.laobserved.com/archive/2015/04/new_parking_signs_...](http://www.laobserved.com/archive/2015/04/new_parking_signs_get_mix.php)

For: [http://www.laobserved.com/archive/2015/04/and_a_vote_for_the...](http://www.laobserved.com/archive/2015/04/and_a_vote_for_the_new_pa.php)

</comment><comment><USER29> They should have made the QR codes bigger, so it would be easier for your car to read them while you're driving down the street.

</comment><comment><USER26> Bad signs.

Fatal flaw: the red / green bars have no context because the the hours & days text is unreadable except up close and hour/days change from sign to sign.

EDIT: also impossible to read when driving / stopping by in your car. You'd have to roll down your window or maybe even get out to read everything.

<comment><USER30> I think these new signs are strictly better than the old signs. If you can make them more betterer then I and the rest of the world would love to see it. Someone random from the internet redesigning signs is how these came about. Let's see what you got.

<comment><USER31> I'm not the parent poster, but I am colorblind. The green and red bars of these signs are difficult to discriminate for me, and I suspect many others.

The design could easily be improved by using different colors, since ~10% of males have some color vision deficiency. Few people have deficiency in their short-wavelength cones (blue), so blue/yellow could work, or better still would be simple black and white, or some sort of spatial modulation difference (solid/striped or border/no border).

<comment><USER4> So the stripes are too faint to make the red areas sufficiently distinct?

The obvious problem with an alternate color scheme is that it wouldn't instantly convey 'good or bad' in the way green and red do (to people with adequate color perception).

<comment><USER31> The stripes are too close together, and the contrast is low. They're subtle up close, and difficult to see from a distance. If the spatial frequency were lower (larger stripes) and if they used alternating lines of white and the current color, it might be alright.

</comment></comment></comment></comment></comment><comment><USER32> To me it would just seem more intuitive to have time go from down-->up. These signs seem to do the exact opposite.

<comment><USER33> ENGINEER?

TRAFFIC

ARE YOU A</comment></comment>


Ask HN: Client Password Management - <AUTHOR>

I work at a small company that interacts with a lot of clients.  We frequently have to get on their FTP servers, in their hosting accounts, and more.  As such, we have a large amount of client account and password information that was previously just written down and placed in file cabinets with other documents.  This made sharing the passwords difficult and resulted in going back to the client to ask for passwords several times.
When I got the the company I decided it would make things easier and more efficient to set up a better system.  I installed Dropbox and KeePass on all systems and built a protected password database for our office.  It has made things much more efficient.
However, with this setup, it opens us up to problems.  This is purely hypothetical at this point, but it crossed my mind yesterday.
What if we hired an employee and later fired them and they decided to get revenge by using the passwords that they (could have) easily backed up to abuse client (and our own) accounts?  Is there legal protection?  Is our system terrible?  What are your thoughts? <comment><USER2> \- A policy of giving passwords to an employee in a need-to-know basis.

\- Change those passwords when an employee leaves.

You need to keep track of the passwords that each employee know. A simple DB will do.

<comment><AUTHOR> The need-to-know basis is good, but defeats the purpose of having the shared database. If we could tier access, and grant permissions, then that might be a more viable option. I'll look into it.

We can change our own passwords when an employee leaves, but that leaves all of the client passwords. If we set up their (for example) hosting account and solely managed it, changing the password would be fine. However, we have a large number of clients who co-manage stuff with us -- we both access their hosting, domain registrar, mailchimp/constant contact, advertising, etc accounts. We can't really go through and change a few hundred client passwords or email them urging them to change passwords so that one of our employees doesn't screw with them.</comment></comment>


Why node.js disappoints me - <AUTHOR> http://www.eflorenzano.com/blog/post/why-node-disappoints-me/ <comment><USER2> CoffeeScript (<http://coffeescript.org>) is my attempt to solve this exact problem. Take the parts of JavaScript that work well, fix the broken areas (statements-vs-expressions, variable scoping, difficult prototype chains), add features (like the array comprehensions mentioned in the article) ... and compile it all to lowest-common-denominator JavaScript that runs just as fast as the JS-you-would-have-written-yourself, and runs just fine from V8 to IE6.

If you want JS with nice features, and not to have to worry about JS language support, do yourself a favor and check it out.

<comment><USER3> I like CoffeeScript, but what does it have to do with Eric's complaints? It does nothing to prevent people from duplicating effort or tying libraries to a specific environment.

<comment><USER2> Eric complained about implementation-specific language features in JavaScript -- things that only run on some, but not all of: SpiderMonkey, V8, JScript, and Nitro. To quote:

        Instead of coding in one language, we're actually coding
        in two. One is the subset JavaScript that can be run in
        all browsers, and another is the set of JavaScript that
        can be run by Node.

He's not talking about features specific to the Node API, but to features present in V8 that are lacking in older versions of JScript, effectively. A lot of Node libraries use features like Array#forEach, Object.create, Array#indexOf, Function#bind, making libraries unusable in the browser, even when they should be able to run perfectly well there.

CoffeeScript doesn't prevent you from using implementation-specific features if you want to, but provides in-language alternatives to all of the things listed above, in a cross-browser fashion.

Objective-J works in the same way, doesn't it? It's possible to write Objective-J code that is tied to a particular runtime, but if you write in the regular style, you won't have any cross-browser trouble.

<comment><USER3> When he said "language" I guess I automatically translated that to "APIs" since that's usually what people mean when they complain about incompatibility in JavaScript environments.

Differences in the JavaScript _language_ in engines are fairly minimal these days (BTW all the features you mentioned can be added to legacy engines, see [http://github.com/280north/narwhal/blob/master/engines/defau...](http://github.com/280north/narwhal/blob/master/engines/default/lib/global- es5.js)) I think the bigger problem with sharing code between client and server is the libraries that unnecessarily tie themselves to APIs specific to each environment (i.e. the DOM and other browser APIs, and Node.js or other server-side APIs)

<comment><USER2> First -- your global-es5.js module is awesome. I frequently point folks to it for a way to bring old browsers up to speed. But at the same time, if you don't include a library like it, you have to admit that there are 30 core functions in there that it's easy to depend on, and that the global-es5 implementation isn't perfectly compatible with real browser implementations, it's just very close (Object.getPrototypeOf being a good example of something you can't fix).

The other approach, and the one that Eric is lamenting, is writing lowest- common-denominator JavaScript. The problem he calls out in Node isn't that it's not possible to write cross-implementation libraries -- but that people aren't doing it. There are tons of Node libraries which could very easily run in the browser, but don't. Just browsing through NPM, here are three random ones:

<http://github.com/visionmedia/lingo/>

<http://github.com/Marak/Faker.js/>

<http://github.com/past/speller/>

All of those do nothing Node-specific, but use JavaScript features that aren't present in IE6, 7, and 8.

</comment></comment></comment></comment></comment><comment><USER4> I am of the opinion that there is no longer a need for server side templating languages and that they only serve to complicate the technology stack. With REST services, Javascript, CSS and HTML the technology stack for web development has become significantly simplified due to the fact that it is once again digestible. A designer can know HTML and CSS and provide designer services without having to know the intricacies of a back end technology (many times several) further they can graduate into JavaScript UI programming as they grow and gain experience. Finally they can grow into developing back end services. With modern web development the layers have become compartmentalized or black boxed to shield each layer from the implementation details of the others. This is a good thing because a new developer does not have to master "technology soup" to become the lowest level of proficient. With current trends in web development, server side UI frameworks make no sense. The take a longer development cycle and they produce inferior results.

<comment><USER5> I think a lot more people will start considering this possibility seriously the day Google announces it parses Javascript.

<comment><USER6> I won't. The web for me is URLs and HTML. JavaScript is for providing user experience enhancements on top of that. I don't want a Web which can only be understood by running a JavaScript interpreter against it.

<comment><USER7> I used to agree, but now I actually think there are two webs. There is the original web, the document web, but there is also the application web. Sometimes the two overlap, and almost every site has at least some documents that should be plain ol' HTML.

However in working on the application web for the last 5 years I've come to appreciate the power of new approaches for web-based user applications. It turns out that generating full HTML pages for users can turn into an incredible waste of resources and significantly worse UX, for what amounts to a very tiny accessibility and SEO advantage. Facebook is the canonical example here. The way they load a page is brilliant from a UX and server resource perspective.

But consider apps that are much less dynamic. Say you have a 50k page with 1k of dynamic content per user or some other variable such as country. Page caching is impossible. You can rig up all kinds of complex server side fragment caching mechanisms, and squeeze quite a bit of performance out. However these schemes quickly grow very complex, whereas the client/server architecture lends itself to a solution that is _orders of magnitude_ more elegant, which is simply to load the dynamic bits via AJAX. This A) offloads processing to the client, B) solves all kinds of caching problems, allowing full HTTP caching where it would have been impossible, and bypasses hordes of thorny cache invalidation problems, C) creates some elegant optimizations that would have chicken-or-egg problems if attempted on a server-side MVC architecture alone, D) Improves page responsiveness dramatically as the initial HTML shell and static assets can start loading almost instantaneously, and E) allows a more de-coupled architecture that makes sharding and scaling much easier.

Because of the technical advantages, it's inevitable that web-based app development will continue moving in this direction. Web apps that don't go in this direction will be at a disadvantage from an operating cost and UX perspective.

</comment></comment></comment></comment><comment><USER8> While GWT, Pyjamas, and other such toolkits have a ways to go I think there is some reason to believe that in the end they might work out.

For example, Pyjamas just got a kickstart in development (again) and released a compiler that can target both javascript and GTK from a single codebase. It also incorporates a JSON-RPC client, effectively abstracting out backend calls into what appear to be normal Python methods in the source.

My idea was to couple Pyjamas as an alternative front-end to normal template packages. You could theoretically write your entire application, UI code and all, in normal Python. The UI code would be heavily coupled to your backend code as if there were no seperation between the two. Once compiled to the javascript target, the interface should work just as well without any notice from you, the humble developer (making calls over JSON-RPC).

Check out my fork of Pylons on bitbucket to see how I've made wsgi apps speak json-rpc. It's a start. The problem right now is that I've heard many people moan that Pyjamas (and even GWT for that matter) do not spit out the best js. Something that could use improvement over time (and something I think will as long as there are interested developers). Either way, the next step is to write a paster template plugin to setup a project for using Pyjamas and a distribute pluging to add a compilation step to the build process.

</comment><comment><USER9> It sounds like the problem he's having isn't with Node, but with the libraries people have built on top of node.

He's arguing that somehow using libraries makes it a "different language" than the one you'd use in the browser.

<comment><USER10> Well some of the libraries out there are glue for C++ code. I think that is what he was inferring anyways.

<comment><USER9> I don't see how the argument is any different than saying you have to use a "different Python" for web development and client-server development.

<comment><USER11> It's a little bigger consideration in this case imo, because one of the big selling points is the ability to do "JS everywhere" and share code between the browser and server side of apps. Not that that's the only reason node.js exists, but it's a nice aspect that becomes harder if the server and browser sides diverge more.

<comment><USER9> Ah, if that's the case then I misread.

If the problem is the broken promise of writing code once than runs perfectly well on the server or in the browser then I guess I could see the frustration. Although, I'm not sure that's an entirely realistic expectation given the different roles you'd expect the server and client to fill.

</comment></comment></comment></comment></comment><comment><USER3> When I started doing server side JavaScript a few years ago I was frustrated by JavaScript libraries which were unnecessarily tied to browser-specific APIs like the DOM. That seems to have been somewhat fixed. Now I'm frustrated by the reverse.

The first step to fixing this is getting good implementations of CommonJS modules in the browser. JavaScript needs a module system (no, <script> tags are not good enough) and CommonJS is the closest thing we have to a standard that can be added to existing environments.

Also important for interoperability is making sure people don't use proprietary extensions to CommonJS modules, which Node unfortunately has plenty of.

</comment><comment><USER12> I don't understand the applause for Javascript. Yeah, we've unified on one language for client-side and server-side, but I _don't like_ programming in Javascript. Why would I move to Javascript for server-side when I could program in Python and minimize the amount of JS I actually have to write?

Does everyone just like Javascript?

<comment><USER6> Have you ever taken the time to learn it? JavaScript is a pretty neat little language - the way it does functions and closures allows for a programming style that doesn't really work in Python (due to the lack of multi-line lambdas).

My eyes were first opened to JavaScript during my Computer Science degree, during a course on Programming Languages - the professor spent a full lecture on how interesting it is, and it completely changed my opinion of the language.

<comment><USER12> <rant>

 _Have you ever taken the time to learn it? JavaScript is a pretty neat little language - the way it does functions and closures allows for a programming style that doesn't really work in Python (due to the lack of multi-line lambdas)._

Yes, I have, that's why I said I don't like programming in Javascript, not that I don't know Javascript. Most of the design decisions serve to frustrate me more than empower me. The variable context I'm working in always seems always a bit mystical. Their method of FFF has a lisp air but they way it's written always makes it seem like more of a bastardization than an homage.

Python doesn't have multiline anonymous functions, but it does have inner functions. Given that I find the style of doSomething(function () { something; something; something; }); verbose and confusing, I prefer Python's implementation.

In Javascript there is More Than One Way To Do It(TM). Sometimes I don't mind this -- writing Haskell has never felt anything like writing Python. In fact, writing Haskell almost feels like writing a proof (and for good reason, look into the type system theoretics if you're interested) instead of a program. Therefore when writing Haskell I never feel like I need to make a comparison to languages like Python. They work differently and will be used by for different things.

Javascript, on the other hand, feels bland and conventional and begs for me to compare it to languages like Python. When I do I realize that the modularity, import system, and library of functions I've written in Python have disappeared into the wind, along with the ability to jump to C when necessary for performance.

In fact, when it comes to performance, Javascript is the worst! Not that Javascript performance itself is terrible as a scripting language, but that There Is More Than One Way To Do It but Only One Way Is Fast. The JQuery author is an expert at this, as well as some of my good friends at Google. There's always been a Book of Javascript, passed from developer to developer, that says what the Fast Way is. I hate that. I don't want to have to memorize idioms if I want my code to be performant. In summary, I guess, I want Python ;)

</rant>

</comment></comment></comment><comment><USER13> tl;dr -- if the only reason you'd consider "swallowing the bitter pill" of programming in JS on the server is because of the fallacy that you can get a single codebase for the client and server, then node isn't for you.

Way to knock down the straw man, you really showed 'em.

Look around on <http://nodejs.org/> and tell me where I can read that one of node's stated goals was to facilitate a single codebase between the client and server?

Head on over to the node.js mailing list and you'll find a very sharply divided community when it comes to this question (one codebase for client/server), not surprisingly.

In my opinion, many (although certainly not all) of the people out there talking about one-codebase-to-rule-them-all are doing so mostly out of a shallow grasp of the domains in question. I'm not trying to be derisive here or bring the wrath of the gods down upon me, but you just have to accept that the client and server are different environments/platforms, period. Attempts to seek the "silver bullet" in this regard will end as most, if not all, other such attempts have: outright failure or, at best, mediocrity.

Putting the merits (or lack thereof) of my previous paragraph aside, if the question in your mind that follows from that is: "then why use node? javascript blows/is meh/is not ruby/etc?", well, I would respectfully beg to differ. The laissez-faire nature of javascript is pretty empowering, to me, and I enjoy it greatly. Additionally, node.js is novel in the manner in which is leverages the power of V8 and is built from, basically, the bare-metal on- up as an evented architecture (the same cannot be said for twisted or eventmachine). It's more than _just_ throwing a bone to developers with a predominantly client/javascript-based portfolio and I think it's disingenuous to dismiss or characterize node's appeal as such (and yeah, now I'm building the straw men).

</comment><comment><USER14> I'll probably get downvoted (again) for tooting my own horn, but I am developing a JavaScript framework to definitively solve the JavaScript templating problem.

<http://www.jaxscript.com>

Here's a screencast version of a presentation I did for a local user group: <http://vimeo.com/15127654>

The technology works, it's really, really solid. I think all server-side template languages are going to be obsolete a lot faster than most developers are prepared for.

<comment><USER15> Interesting idea. A few comments:

\- It would be nice to see some more detail on your page. Writing stuff down might help with ideas too.

\- The video is too laboured. Too slow. I lasted 9 minutes, and was very interested, but that was as long as I could last. You need to script video fairly tightly to hold folk's attention. You can get away with more space when live, but it doesn't translate to video. There's a reason film makers storyboard.

Anyway, I look forward to hearing about progress. I've just started exploring PhoneGap, so what you are doing is definitely of interest.

<comment><USER14> Yeah I know what you mean. I'm not terribly experienced with screencasts, and I did this one mainly for practice before a live presentation. I posted it for people who weren't in attendance, but thought perhaps others might be interested.

</comment></comment></comment><comment><USER16> He misses the point. You still need to operate in two different environments, but it's possible to share a large set of code, business logic and helper functionality.

</comment><comment><USER17> The beauty of javascript is that it is supported in multiple environments (various browsers, rhino, v8, etc). But with that comes VM specific implementations, and that's real life.

To truly achieve what the author said, programmer has to dumb-down their javascript to the lowest common denominator. Or have one common library to make sure all javascript features are supported, even if some have to be written in javascript.

Take array comprehension for example (<https://developer.mozilla.org/en/New_in_JavaScript_1.7>). Rhino, since it's a Mozilla thing, supports it. How about IE? I'm not sure if V8 even supports that.

Separation between server side and client side is bound to happen. Especially since it's a lot easier to use bleeding edge features on server side.

<comment><USER2> Except that there are plenty of cross-browser-incompatible features that aren't exactly "bleeding-edge", unfortunately.

For example, in IE < 9, there is no implementation of "Array#indexOf" -- the only way to check if a value is present in an array is to write out a loop to check each element.

</comment></comment><comment><USER18> Node's strength are in doing streaming UIs. Like realtime twitter feeds that push new tweets to the UI the moment they come in. It also does allow sharing code such as client side and server side validation. And if you use require.js you can develop modules that work server aide and client side.

Node.js does add new features, it's ease of use is a feature. Server side push used to be more complicated than it had to be. Python has twisted which I found difficult to setup as it required Python skills which I was rusty on and was more abstracted than I needed.

And of course server side JavaScript really is great, I don't see how it's that hard to understand two environments. You can't get rid of that they are different environments but they can share much code and does require one less language to use than most web app frameworks.

</comment><comment><USER19> I think the author has a valid point, but I disagree with his tone. I feel like those of us who were speaking about this early on always said that the browser would be the constraint.

This is why Yahoo has been working on using YUI3 in Node to offer an API layer that works both in the browser and the server. ([http://www.yuiblog.com/blog/2010/04/09/node-js-yui-3-dom- man...](http://www.yuiblog.com/blog/2010/04/09/node-js-yui-3-dom-manipulation- oh-my/))

The latest demos of this have Expressjs being used to render using a YUI3 based templating (<http://express.davglass.com/>).

</comment><comment><USER20> I came into this one language concept in 2006. Back then there were already helma.org, which has functionality of RoR but it has being around since 1999.

Now Helma NG is relunched as RingoJS.org I would highly recommend checking it out.

<comment><USER7> Wow you really missed the boat. You should have checked out Foobar FU which had Rails 3 functionality back in 1995. The one-language thing was already played out by 2004.

</comment></comment><comment><USER21> Actually this is not Node.js's fault, you could easily create your own templating library that suits your purpose. Node is not an all in one solution.

</comment><comment><USER22> Weblocks and Parenscript and CL-WHO and hu.dwim.perec and I write code in only one language too.

<comment><USER23> There is a good chance you might _lose_ doing that.

Use Lisp for its strengths, and other technologies for theirs. Server side CL, client side jQuery, Postgres on the backend, and your choice of caches, proxies and middle-ware in between.

I have tried nearly every other combination of New Thing and Hyped Awesome, and came to this conclusion: don't do everything yourself, and don't use technologies others are not investing big $ in. Anyone can push something to github and launch a nice tryfoo.org site, that doesn't mean you should use it.

FWIW, I am migrating my entire web toolchain to the JVM and intend to start writing servlets in Lisp. Let Big Business be my R&D bitch. JVM is good enough, and it's posh.

</comment></comment><comment><USER24> The title is misleading. It is not node.js that disappoints you.

</comment><comment><USER10> The underlying problem is the kool aid drinking, not node.js

<comment><USER25> I'd say the problem is people expecting that any new technology is revolutionary.

<comment><USER26> I think the underlying problem is programmers who aren't very good at programming. That means they're constantly on the look out for some magic potion that will make it easier for them.

Of course some things do make it easier - frameworks, libraries etc. But they often only make it easier at the start before your project gets complex and needs custom out of the box things.

Programmers should just knuckle down and try to improve their skills rather than chasing the latest fads.</comment></comment></comment>


What forms do I need to make sure to file for my startup's C-Corp taxes? - <AUTHOR> As a quick background, I opened my Delaware c-corp this past summer and wanted to make sure I was filing the correct forms. I need to file a Form S-1120 (federal), and pay Delaware franchise taxes. Is there State taxes I have to pay? My startup is based in NYC.<p>My startup has minimal expenses (website operating fees, few hundred spent on ads, incorporation costs) so I'm trying to file my c-corp taxes by myself. <comment><USER2> Get an accountant, keep it clean. You don't want fines and penalties. Have you been paying estimates throughout the year?

Most likely, you do have to pay state taxes in addition to federal and Delaware franchise. Them NY taxes are on the stiff side too</comment>


Should I feel obligated to work extra hours because of project mismanagement? - <AUTHOR> http://workplace.stackexchange.com/a/48280/3342

<comment><USER2> Agreed 100%. In my experience, barring servers falling over, _everything_ can wait until tomorrow (or Monday). If you send me an email at 5:15pm, then you can reasonably expect a response tomorrow morning before noon. If you give me a task on Friday afternoon, you can reasonably expect me to begin it on Monday morning. If you set an unreasonable deadline, that's not my problem. (And if you make it my problem, this is no longer particularly a place I want to work.)

Now, to be fair to employers, it occasionally _makes more sense_ to do something on a weekend or late at night, such as a deploy that involves downtime or some other critical factor, but it should not be _required_. As a manager in these kinds of scenarios, I ask for volunteers or I do it myself. I've never actually had to do it myself. Someone always volunteers to keep me company.

But the point is that it's not required. If your boss tells you to work late, or your coworkers shame you into working late or weekends, run the other way.

If you enjoy working long hours and giving up your weekends, knock yourself out. But don't do it just because someone else can't manage a project. (And, of course, if you decide to push back on this, do so respectfully, firmly, logically, and with full confidence that your time is valuable -- especially time with family and friends.)

</comment><comment><USER3> Great response.

I am from Italy and I really care about productivity. What I realized is that rarely more hours results in better work.

The thing is: If you care about quality, then being too much pressured or fast-paced might lower quality. If you care about quantity... then why the hell are you paying a so-skilled person to do "quantity"-work.

Now...a small question. After I began reading HN and some startup info, I got the impression that, in many fast paced startups, this might be a "common issue", is there someone who could confirm this or I'm just making this up by myself?

I want to understand if the startup world (almost non-existent in italy compared to the rest of the world) consider the human behaviour a big part of the game or not. Right now I find that few startups or companies publicy share how they handle this situations and what they do to avoid this streaks.</comment>


Apple store in Germany defaced with huge Windows logo | Technically Incorrect - <AUTHOR> http://news.cnet.com/8301-17852_3-20069023-71/apple-store-in-germany-defaced-with-huge-windows-logo/ <comment><USER2> really M$!!! It would have make sense if they painted TUX though.</comment>


Website Personalisation for Non-FAANG Companies - <AUTHOR> https://jay.kanakiya.in/blog/website-personalization-for-non-faang-companies/ <comment><USER2> Wow, pretty much everything that article suggests are the very things that drive me away from websites.</comment>


Tor: 'Mystery' spike in hidden addresses - <AUTHOR> http://www.bbc.co.uk/news/technology-35614335 <comment><USER2> Bitcoin Core v0.12.0 was just released.

From the release notes,

      Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket API, to create and destroy 'ephemeral' hidden services programmatically. Bitcoin Core has been updated to make use of this.

      This means that if Tor is running (and proper authorization is available), Bitcoin Core automatically creates a hidden service to listen on, without manual configuration. Bitcoin Core will also use Tor automatically to connect to other .onion nodes if the control socket can be successfully opened. This will positively affect the number of available .onion nodes and their usage.

      This new feature is enabled by default if Bitcoin Core is listening, and a connection to Tor can be made. It can be configured with the -listenonion, -torcontrol and -torpassword settings. To show verbose debugging information, pass -debug=tor

[https://github.com/bitcoin/bitcoin/blob/master/doc/release-n...](https://github.com/bitcoin/bitcoin/blob/master/doc/release- notes/release-notes-0.12.0.md#automatically-use-tor-hidden-services)

<comment><USER3> There are around 200 nodes with 12.0 installed as of now. [https://bitnodes.21.co/nodes/?q=/Satoshi:0.12.0/](https://bitnodes.21.co/nodes/?q=/Satoshi:0.12.0/)

Not all of them are going to be on machines with Tor running.

</comment></comment><comment><USER4> A different hypothesis on the tor-talk list was a piece of ransomware that generates a hidden service per victim:

[https://lists.torproject.org/pipermail/tor- talk/2016-Februar...](https://lists.torproject.org/pipermail/tor- talk/2016-February/040318.html)

<comment><USER5> Exactly my first reaction.

At the moment we get hundreds of Locky mails per day.

There is a huge spike in ransomware at the moment. And all ransom has to be paid via a tor location.

<comment><USER6> We started blocking .docm at the mail server (it uses a Word macro to download)

<comment><USER7> That won't block all macro viruses. You need a dedicated program/firewall for this, filtering on extension won't work. Older .doc formats can also have macro's included and will work in newer (as well as older) versions of word.

<comment><USER6> This was just to prevent this specific attack - kind of a stopgap until the AV detects it properly.

IIRC last time I checked the Word doc on virustotal it was picked up 22/55.

Fortunately at least AV did pick up the payload when a user let the macro run...

Edit, ran it by virustotal again and got 28/55

</comment></comment></comment></comment></comment><comment><USER8> This is a blogspam version of [http://www.profwoodward.org/2016/02/what-just- happened-on-to...](http://www.profwoodward.org/2016/02/what-just-happened-on- tor-network.html)

<comment><USER9> Which is blogspam of [https://lists.torproject.org/pipermail/tor- talk/2016-Februar...](https://lists.torproject.org/pipermail/tor- talk/2016-February/040302.html)

</comment></comment><comment><USER10> Could this be related to Ricochet getting press?

<comment><USER11> From the article:

 _One possibility, he said, might be a sudden swell in the popularity of Ricochet, an app that uses Tor to allow anonymous instant messaging between users._

</comment></comment><comment><USER12> Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket API, to create and destroy 'ephemeral' hidden services programmatically. Bitcoin Core has been updated to make use of this.

This means that if Tor is running (and proper authorization is available), Bitcoin Core automatically creates a hidden service to listen on, without manual configuration. Bitcoin Core will also use Tor automatically to connect to other .onion nodes if the control socket can be successfully opened. This will positively affect the number of available .onion nodes and their usage.

This new feature is enabled by default if Bitcoin Core is listening, and a connection to Tor can be made. It can be configured with the -listenonion, -torcontrol and -torpassword settings. To show verbose debugging information, pass -debug=tor.

</comment><comment><USER13> Measuring the Leakage of Onion at the Root:

[https://www.petsymposium.org/2014/papers/Thomas.pdf](https://www.petsymposium.org/2014/papers/Thomas.pdf)

</comment><comment><USER14> are these spikes in exit nodes ?

<comment><USER15> no, these are spikes in hidden services.</comment></comment>