vemv

56 ms·

571.
by vemv 11y ago
I think the software architect role is outdated by now? I've yet to meet even a CTO that doesn't get his hands dirty with code from time to time.
572.
by vemv 12y ago
As a backend (Rails, in particular) dev, most tasks are really streamlined - I've done them 1000 times before pretty much the same way I would do now. There is room for unpredictability, debugging hours, etc but those are rare. I can s
573.
by vemv 12y ago
Great input, I feel relieved to read that my 4:30 (of pure coding work) is good, according a profile like yours. Personally I'm kinda afraid that some developers out there might be pulling actual 8 hours of overhead-free progress, unli
574.
How many hours do you work a day (developers)?
55 points by vemv 12y ago|54 comments
575.
by vemv 12y ago
I'd hire a secretary and dictate whatever I want to do (not limited to typing: window switching, etc). A sophisticated multi-monitor setup would help.
576.
by vemv 13y ago
On your edit: yeah, using both hands for composite commands is good practice. That way fingers keep in more natural positions. Still, using the palm for pressing Ctrl is bad. The hand should tend to be kept convex, not concave or flat.
577.
by vemv 13y ago
Using the palm to press the modifier keys is extremely poor advice. Move your whole arm/had and use the index finger instead. Never the pinky. Follow the pattern of moving the arms in general. Avoid contorting the wrists. Ergonomic key
578.
by vemv 13y ago
All arithmetic operations on these boxed objects are significantly slower than on their primitive counterparts. This implementation also creates an unnecessary intermediate sequence (the result of the map), rather than ju
579.
by vemv 13y ago
I don't see anything inherent to node/v8/js that would be limiting. The concurrency model.
580.
by vemv 13y ago
Nobody said that anyway. I doubt there's such a thing as non-side-effecting languages :)
581.
by vemv 14y ago
For the record, my initial impression about Pedestal isn't particularly positive either. But I don't think one can judge its complexity only in terms of familiarity. Probably the problem with "too many knobs" isn't the cardinality itself
582.
by vemv 14y ago
No, that's missing Rich's point - "complexity and cardinality are orthogonal". AFAICT, Leiningen is the living proof that you can build an all-encompassing architecture without renouncing to simplicity.
583.
by vemv 14y ago
This is definitely going to be a FAQ. I believe spanning disparate concerns doesn't necessarily add complexity - only size is certain to be added. Which isn't particularly wrong as long as the concerns are not coupled.
584.
by vemv 14y ago
I'd use a sorted set.
585.
by vemv 14y ago
Parallelization has some fixed cost, so for small (i.e. most ) work loads, using it results in worse performance. So I don't see reducers (or clojure.core/pmap, for that matter) becoming the default. Generally, the part of a program worth
586.
by vemv 14y ago
The work-stealing part can be understood as automatic, but Java's FJ is responsible for that AFAICT. Having to state "do this in parallel" (by using clojure.core.reducers fns instead of their clojure.core counterparts) is not automatic but
587.
by vemv 14y ago
"If our caches are always coherent then why do we worry about visibility when writing concurrent programs? This is because within our cores, in their quest for ever greater performance, data modifications can appear out-of-order to other t
588.
by vemv 14y ago
Not Heroku's fault in this case, Rails (and any other single-threaded environment) can handle a single request at a time.
589.
by vemv 14y ago
I'm sorry but I fail to see much value in this pamphlet. It's just the same old message from Typesafe (productivity! scalability!) wrapped with buzzwords and anecdotical data.
590.
by vemv 14y ago
The occasional worthwhile submission justifies reading HN regularly, but I consider the general signal/noise ratio rather low - some parameters ought to be tuned.
591.
by vemv 14y ago
In fact many of the listed practices are common to all programming languages.
592.
by vemv 14y ago
Well that was unexpected! It makes me curious about the Erlang way. Thanks for the reply.
593.
by vemv 14y ago
Why not program defensively?
594.
by vemv 14y ago
Fabio's approach does the job, but it fails at genericity - its usefulness is limited to the scope of the Formotion project. Which is unfortunate because something actually simple is going on - a mapping of keywords to functions. What you r
595.
by vemv 14y ago
Here you go: http://blog.markwatson.com/2012/07/my-simple-hack-for-using-... From what I know, lein's policy is to make adding .jars as hard as possible. Update: just found this other method http://www.pgrs.net/2011/10/30/using-local-jar
596.
by vemv 14y ago
Characterizing side-effects as a series of supposedly functional transformations doesn't sound quite alright to me. That said I'm curious about such an approach.
597.
by vemv 14y ago
I'm afraid you're confusing data structures (such as vectors, sets and maps) with the document model object. Not even in JS the DOM and objects are the same - some properties of the DOM have 'magical behavior' attached. ClojureScript does n
598.
by vemv 14y ago
I'd say that not having "the whole language, all the time" is only (potentially) a pain regarding the development process/experience itself, not the quality of the resulting programs - which is what matters at the end.
599.
by vemv 14y ago
On server-side templating - did you consider a selector-based approach like cgrand's Enlive? As I see it, it brings the best of both worlds (the comprehensibility of "logicful" templating, the maintainability of strictly separating presenta
600.
by vemv 14y ago
Good to know, thank you.

More ›