JCraig

Tomatoes are quite prolific and can be used in many types of dishes. For sauce, I like plum varieties roasted or dried; for sandwiches and snacking, I like black russians or yellow grape varieties.

Some people have already mentioned chilis as a good crop to grow along with tomatoes. Might as well grow cilantro too and you're halfway to a decent salsa (buy the onions, they ripen at a different time of year).

I also like to grow basil alongside my tomatoes. You can buy a nursery plant for the same cost as buying fresh basil for cooking from the grocery store, and the basil plant will produce all summer long. Sweet basil is great for pestos, margherita sandwiches and pizzas, and marinara sauce. Thai basil (which tastes of anise) is great for curries.

On the whole, I find that growing my own herbs gives me the most bang for the buck. It's still worth it to grow tomatoes since there's no way you can match the taste of a home-grown one.

Take a look at cdnjs.com. They haven't updated to 4 yet, but I wouldn't be surprised if they did soon. They have many more libraries than Google's or Microsoft's CDNs.

I've been looking at exactly this issue this last week. I have a logo with a gradient and a small border outline for increased legibility. I'd much rather do this in html/css than as an image, but I'm going with an image for now since these text features are a moving target.

I agree the examples are a little garish, but if you look around, most logos are some mix of these attributes (font, stroke, fill). And it would be much easier (for me) to resize and update logos in html/css than to have to supply 3 or more versions every time I need to create or update a logo.

I have a great respect for the attitude that goes into running 37 Signals. Making something simple, enjoyable, and useful is much more concrete, from a development standpoint, than making something "the best". It also allows 37 Signals to sidestep the trap of defining oneself by competitors. This seems to allow them to spend their energy on making their products and their lives good.

Jason Fried has talked before about the importance of making things simple and easy. Simple and easy to use are hard to categorize as "best" when selling a product to customers or investors. Having more features, doing more work, saying "yes" more often gives you easier metrics to claim "best", but they often lead to overly-complex and difficult to use products and harried, stressed, unhappy employees.

Of the people who have approached me to possibly work with them, I have yet to encounter one totally original idea. Often, they'll tell me it's original, but a quick Google search will turn up a few to a few dozen competitors already in the space.

It doesn't mean the idea is bad, and it doesn't mean that a good execution of the idea won't be successful. But, there's no reason for an NDA, and there's no reason to be concerned I will steal the idea.

The implementation is key. If the person with the idea also figured out what the user interactions will be like, what types of data are needed, and what separates the product from direct or indirect competitors, I might be interested. If the person only has a vague idea of a project management system that addresses the market between Microsoft Project and Basecamp (an idea I've been pitched more than once), I'm not interested.

I'm also no longer interested in signing an NDA before discussing an idea. If we get further into business plans, financial information, and specific implementations, sure. But by then, I've already agreed to work on the project, and I'm getting compensation in return.

At my last position, we were told that it was expected to refactor every time we updated any module. However, we had no list of things that needed to be refactored, no real team programming patterns or standards, and we were rewarded almost solely on implementing new features quickly. Sure, someone could refactor code and make it easier for others in the future, but there was never a reward for that, and often there were questions about why it took extra time to implement.

Without team standards, a list of things to refactor (if available), and rewards or recognition for actually making cleaner, more maintainable code, most developers will do what gets them recognition, pay raises, and such. The thing that often gets recognized is implementing new, visible features.

With only 2% of visitors coming from mobile, why would they go mobile-first?

Sure, the design of the site might limit mobile use a bit, but it probably wouldn't cause that big of a disparity in and of itself.

Also, the post mentioned good reasons to go responsive or mobile-first and said that the benefits to a fixed layout for most pages outweighed the drawbacks for them. They have even optimized some pages for mobile where it makes sense to them.

Doing what is right for your business is more important than jumping on the newest techniques solely to be seen as "innovative".

Tortoises were the first to come to mind for me. Later in the article, it does state that it's not just size but metabolism that figures into this correlation.

That being said. The article states that this relationship governs "all life" but only gives data for plants. Even there, "some variation, but not a lot" is an extremely generous representation. For the same mass, a difference in mortality rate could be 10^3 or more if I'm reading the graph correctly. While the relationship might roughly follow a trend, I wouldn't call that "not a lot" of variation. It's interesting, but I think the authors are overselling the relationship.

I was thrown off by Might stating that "a grammar defines a language," which is not nearly as useful or factual as saying that it "describes" a language, the wording that he relies on throughout the rest of the article. That is the difference between me being able to make a dog or identify a dog based on a set of characteristics.

Grammars are only one part of understanding a language, hardly the "language of languages". In natural languages, grammars are one subset of linguistics. It would be just as valid to say vocabularies or phonology are the language of languages as it would be to say grammars are.

Other than these overly broad arguments and attempts to define natural languages in the same way that formal languages can be defined, this is a nice general introduction to some specific notation techniques for computer languages.

Of course, I might not have read it at all if it were titled "An Introduction to Backus-Naur Form, Extendend BNF, and Augmented BNF Notation Techniques".

Since it is so easy to game card-based check-ins, I'm sure the teachers still have to verify attendance. Also, if a student's card isn't working, they have to be able to count that student as in attendance. I wonder how much time this actually saves.

There has been quite a bit of push-back to the use of RFID specifically. My college used magstripe cards. They're not quite as robust, but they do need physical contact to read the information. It seems like a fair trade-off considering that these are a) kids and b) they are legally required to be at school (and by extension, school policies carry some force of law).

I believe that Jeff addresses this point in such areas as:

Honestly, I haven’t tried it but I imagine it leaves the risk of getting a relationship off on the wrong foot. And, at the end of the day, a large part of your job satisfaction relies on the relationship between you and your manager.

If I had the feeling that my prospective employer was being dishonest, first I would try to find other employment. And if I couldn't at the time, I would build a bit extra into my request for compensation. Sure, sometimes extra money is worth less satisfaction at work. Usually, however, I'd like both fair compensation and a positive working environment.

Also, I don't want every decision at my job to be a matter of stating extreme options then settling for the commonsense one. I'd rather start with a sensible solution, whether it be in salary negotiations or in project responsibilities and timelines.