Full time coder here, who started to draw/paint 2-3 years back. (You can see my journey so far here: https://www.instagram.com/aqeelvn/)

Haven't read all the response here, so I probably might be repeating, but the basic idea is to spend some quality time actually doing it.

Like other arts this is also something one could learn. Take the time to educate yourself with the concepts in visual art. There is a lot you can learn on your own from resources out there. That was the option available to me mostly.

A solid grasp in drawing is required for making any serious work in representational painting.

Andrew Loomis has written a bunch of books that are now mostly available freely on the web. Its really old but its very good.

For painting, I recommend "Alla Prima" by Richard Schmid. This is not a casual read(even though anyone could enjoy the great paintings). Its full of solid technical concepts and advice. You learn more and more from it as you develop yourselves.

Draw from life as much as possible. Don't depend on photographs during your learning phase(although that is never really over) If you don't understand why that matters, don't bother and just stick to it. Soon you will see the difference :)

Good luck!

Where I work, BCC-ing on all mails is not scalable. Instead a random sample of the mails is sent to ourselves.

Exactly what I thought!

Every one knows the importance of DRY but only few follows it genuinely. This article is a good reminder.

The problem with DRY is that programmers learn that it's a good thing but don't learn when not to apply it. There are very good reasons to repeat yourself. The mantra I learned, which has served me quite well, is: Optimize for less state, less coupling, less complexity and less code...in that order.

I've learned to happily repeat code if it means making my programs/components more stateless, more decoupled or simpler to understand. There's nothing worse than trying to make sense of code where a programmer tried to shoehorn two similar but ultimately different concerns through the same code paths.

I'll also happily add complexity if it means reducing coupling and state and add coupling if it means being stateless. State is the ultimate enemy that makes code inflexible and buggy, especially when it's mutable state.

Curious where "Optimize for less state, less coupling, less complexity and less code...in that order." came from. Would like to read more from that source.

On the other hand I learned not to be too dogmatic about DRY because it becomes costly especially in distributed systems where additional dependencies introduced for reusability sake complicate build process and deployment. Sometimes it's better to copy&paste instead of coupling components.

The trade off is rarely "copy&paste vs coupling components". Typically, you would factor out a third component that the original 2 would use.

Two components are hardly coupled just because they happen to use the same library.

Separating the library does not remove dependency because library version change affects both primary components so the change requires coordination. This is really fundamental in large systems and I was hit by it many times.

Copy & paste sounds bad but what it really says is: let's make that piece an invariant and don't import the library if you only need one short function.

So I would say the trade off boils down to "simplicity vs flexibility"

> library version change affects both primary components

In my experience, it changes neither, because the interface of the library just doesn't change. Of course it depends where you make the separation. Basically, if the interface to your library is big, you either suck at API design, or you traced the wrong boundary.

Now if you happen to only need a small fraction of a sizeable library, I can only suspect the library itself fell prey to scope creep. If there's no way to import what you need, and little more, that probably indicates a problem with the library itself.

Even big libraries which by nature must make many different things can often be separated into different components. Like the SDL for instance.

---

Oh, and I was assuming we were talking about internal dependencies. Like, you write the library which will then be used in different parts of your (possibly big) project. That's very different from external dependencies, which are generally bigger, harder to freeze and harder to update.

If your build process and deployment are forcing you to decomponentize something so you have to copy and paste it, I'd blame those processes instead of saying there's an inherent shortcoming in the idea of composing components.

You can use longer passwords now!

Done!

Haha, its so funny! especially considering the fact that http://www.cucumbertown.com is a recipe site :)

Agree. Its not the most useful class.

Good one! People relying on Cron could benefit from this.

getTimezoneOffset() would return the value after taking care of DST. So there shouldn't be any DST related inconsistencies. Now if the user moves to another timezone, and never hits one of our page, there is no direct way of tracking his/her change in location.

I mean that starting mid-March a user who had previously been in a -8:00 UTC offset would then be in a -7:00 UTC offset and you wouldn't know the timezone offset changed until they visited the website again.

That’s certainly a problem. But this solution is better than being totally off. Worst case the person gets the mail in the previous timezone he registered which should be before the DST.