HN user

rmc00

31 karma
Posts2
Comments28
View on HN

Very true. I recently inherited an application at work that has a dark corner where a past co-worker wrote a crappy, I-hope-nobody-sees-this-code prototype. While the code does produce correct results, it's very messy. Most of the people who really understood how it works have left over the years since it was built too. I've been trying to understand exactly how the application works, and it's way more effort than it should be.

The point is this: build your software right. At the very least, only take reasonable shortcuts, and make sure you come back around to fix your crappy design at some point. The longer it festers, the worse it will get.

Is writing this type of resume really the best means of filtering out an applicant's undesired companies? It would seem to me that the best way to avoid companies you don't want to be involved with is to simply research the company before you apply. With that approach, there's no risk due to the personality or opinions of the recruiter regarding the format of the resume, but you can still end up at the type of company you want to work for.

Yeah I believe it should be somewhat straightforward since the history is stored on your computer. The problem lies in the fact that there's no standardized means of storing browsing history, so every browser requires a different approach. I think these links will get you started for some of the major browsers.

IE: http://www.forensicswiki.org/wiki/Internet_Explorer_History_...

Firefox: http://www.forensicswiki.org/wiki/Mozilla_Firefox_3_History_...

Safari: http://www.forensicswiki.org/wiki/Apple_Safari_History_File_...

There may be libraries to do this, but I wasn't able to find one from a quick search.

I actually grew up in a small town that was built around a factory that made one of the featured products. When the factory closed, unemployment was really high, and a lot of people were upset. I see the same sort of response from IT folks to IT outsourcing too.

I have to wonder though: when a company is getting big and globalizing (and it seems to make sense that a company with an iconic product would be big or getting big), is it really that unexpected that they would move operations? I understand the patriotism behind "Buying American", but when the company has facilities and does business across the globe, it's bigger than America.

I work for a company that provides a mission critical service to a lot of people. Maybe we're just spoiled, but we have multiple failover environments. That means that we can deploy in the afternoon by failing the service over to a hot backup during the deployment. When the deploy is finished, we fail the backup system to the production environment and we deploy to the backups while the primary is running. Since there's 0 downtime, we like to work through the process in the morning/afternoons. No all-nighters here, and its definitely not a nice-to-have service. It's all about architecture and design.

It's pretty exciting to see the iPad coming to the enterprise. I've heard that the company I work for released them to executives a few weeks ago, and it sounds like we're not alone. What's really exciting though is how the enterprise desktop space is on the edge of some big changes.

In the past, workers sat in one location and worked in a predictable pattern for a set amount of time. Workers weren't very comfortable with technology and needed major support. Moreover, work was pretty task-oriented -- it could be modeled with workflow very easily.

The environment of today is quite a contrast. The location and work hours of users are definitely not predictable. Furthermore, assistance and limited options from the IT department can get in the user's way sometimes. Also, knowledge workers spend a lot of time doing unstructured work -- analysis, brainstorming, design -- which is something that is hard to model.

Clearly, the old model for desktop has to change. I don't think we can throw a few departmental applications with a heap of productivity applications at people and call it a job well done. The iPad's introduction into the enterprise is a start that signifies different kinds of devices can be helpful. Desktop virtualization and the cloud probably have a role to play in all this too. For sure, I'll be interested to see how it all plays out.

This is an interesting service to consider from the perspective of both the sender and recipient of an email message.

The value that you create for the recipient is the spam filtering that you mention only as an aside. If someone is paying to send an email message, it's very unlikely that the message is spam. This form of micropayment makes email cost a little bit to senders, but it makes spam lose its cost-effectiveness. As a recipient, you can pretty much guarantee that email coming from this service is not spam. That makes going through your inbox a lot simpler.

On the other hand, value is created for the sender of email too. Because the recipient of the email is (mostly) assured that the message isn't spam, a response is much more likely. It sounds like you have a means (or idea) to guarantee a response too, which obviously amplifies this effect.

I think the service has potential. The first question that comes to my mind is who do you charge? You definitely charge the sender, but do you charge the recipient as well? Also, how do you make this work in a user's existing inbox? It seems like having users check another inbox will decrease the effectiveness of the service.

It's interesting that your solution is sort of an incremental solution to spam. To me, the best solution to spam would be to add authentication to SMTP or a new protocol with widespread adoption. However, your solution is more realistic.

If you don't mind, I'm curious to find out why you view the private cloud as un-cloud-like. I don't think the cloud is defined by where the service is hosted or even how the service is paid for. To me, cloud computing is defined by 3 big ideas.

1. Virtualization is key. I think the cloud is marked by a construction from dynamic pools of virtualized resources.

2. Instead of focusing on individual physical components, the cloud focuses on pools of compute resources. This seems to have led to higher priority for service delivery.

3. Finally, I think the cloud is defined by being convenient for the consumer instead of being convenient for the provider.

Within those constraints, I usually call a cloud private if it is under the control of an enterprise IT organization, in a way similar to older systems. I think of the cloud as public if the provider is mostly in control instead of the tenants.

With that definition of the private cloud in mind, the model offers a lot of advantages to larger IT departments. The private cloud allows IT teams to more quickly provision resources in support of business initiatives. It's also a better way to invest in IT infrastructure. The model is inherently scalable, which means that IT funds can be used to create value instead of keeping the lights on so to speak.

Obviously, private clouds aren't for every IT organization, but I think the private cloud has merit. As organizations globalize and just generally get big, economies of scale can be leveraged internally to increase the quality of IT projects and services.

I would echo the recommendations for Introduction to Information Retrieval. If you want something with the same concepts but a little less math, I liked Search Engine: Information Retrieval in Practice by Bruce Croft, et al as well. If you happen to be a python programmer, Natural Language Processing with Python by Steven Bird has some great examples of text processing.

I've been asking the same questions lately and trying to find the answers. The problem that I've run into is that a lot of designers just feel what is right. It seems very instinctive, which makes it hard for them to pass on knowledge.

One designer that I found who seems to know and actively apply principles of good design is cameron moll (http://cameronmoll.com). Cameron gave a great talk a while back at the HOW Conference, and he posted a pdf to accompany the talk http://cameronmoll.com/archives/2009/05/free_download_good_v.... I think this document is a great starting point to learn about design. Obviously, a 10-page document doesn't cover everything possible, but it recommends a few books for learning more. I haven't been able to pick them up yet, but I suspect you will find them helpful.

1. How Designers Think by Bryan Lawson 2. The Elements of Typographic Style by Robert Bringhurst 3.Universal Principles of Design by William Lidwell, Kritina Holden, Jill Butler 4. The Design of Everyday Things by Donald A. Norman

Despite the question "What are you doing right now?", the value in Twitter is that people answer "What are you thinking right now?" I can use Twitter search to find some things out faster because people's opinions appear on Twitter before they appear on Google.

This is not to say that Twitter will replace Google. No way, this is an entirely different problem. The reason Twitter search makes sense is that it takes the search problem one step forward towards a recommendation problem. With Twitter I can get real opinions from real people. It's not that I can't do that with Google. It's that Twitter is a little faster and a little better.

If I was unclear and suggested that Twitter should become a search engine or acquire a search engine, I apologize. If anything, a search engine might want to consider acquiring Twitter.

That's really cool, but the problem for newspapers is bigger than the medium. I can already pull up the New York Times on my iPhone. Now I can do it on Kindle. Cool, but not big news.

Newspapers are still slow to respond. The news is already out on the Internet before its on the front page of the New York Times.

This definitely helps newspapers, but it's only part of the solution. Another part may perhaps be design? (http://www.37signals.com/svn/posts/1660-jacek-utko-can-desig...)

True Entrepreneurs 17 years ago

"I’ve often believed that the true measure of an entrepreneur’s character comes not during the boom times, but how they react in times of adversity and challenge."

Couldn't be more true! I have a friend who runs his own restaurant. He's successful because of his character and how he responded to diversity. When he was starting out, I remember he would have rather spent his money to get a better stove for the restaurant than a new couch for his living room.

There's definitely a cost to that sort of attitude, but that sort of tenacity makes for a business that just won't die.

Most definitely yet. Twitter search has some real potential. It's growing rapidly as a place that people can search for quick reviews of restaurants, movies, etc.

I found that I like hourly rates better than fixed prices. Fixed prices work great if you have a lot of experience on which you can base estimates. For someone who is an emerging developer, I would suggest starting out at a modest hourly rate. Once you have some credibility, you can bump up the hourly rate or start estimating using fixed price.

Do You Speak HTML? 17 years ago

Yeah, it wasn't much of an article, but the point was still valid. Too many web designers use the div tag for absolutely everything. It works, but there's a reason for the other tags. They create semantics that make the web more accessible.

I believe language and effort are the two main factors for a good signup form. Language means clarity, which makes doing the work easier. Minimizing the amount of effort that actually goes into filling out the form is really important too though.

I really agree that this approach of gradually engaging the customer is the best way to go. The last thing a startup needs is to lose customers just because they can't use the product without going through a ridiculously long signup form.

It just makes sense: don't take the information until you need it. I found another article on A List Apart that may of interest to people who liked this article. http://www.alistapart.com/articles/signupforms

I can't talk much about the passion here, but working short days is not a sign of having too little to do. I would argue that if you absolutely have to work all the time, you've got too much to do. Sometimes less is more.

Consider if you say yes to everything: every new feature, every manager who wants a shorter deadline, every bad idea, EVERYTHING. You would be faced with too many features, too little time, and a poor product.

Short days might mean too little to do, but I think short days mean that a programmer is working on all the right things and none of unimportant things.

So many content creators are brilliant but have a fundamental misunderstanding of the web. It's great to see that they're starting to understand how the web works and what makes it different from other means of communication.

You may want to take a look at comet and long polling. With this method, you can eliminate reliance on a clock (and all the associated headaches).

Using comet/long polling, you can sort of mimic pushing the new pictures to clients. This could be ideal because it wouldn't matter when users load the page. Your mileage may vary, however, depending on your specific requirements.