Ask HN:  Searching for jobs sucks. - <AUTHOR>

I've started the process of looking for work (mainly Javascript, PHP, MySQL, and willing and able to learn anything), and I have to say it really sucks.
The problems are:

   * Same listings across hundreds of websites.
   * Aggregation of aggregation of aggregation.
   * Sometimes applying forces me to create an account on some site I don't care about
   * If I apply to each posting I see that is interesting, I'll likely apply for the same job 5 times.
   * URLs that expire in short amount of time
 As a result, I'm finding it impossible to keep myself organized.  Have I already applied for this listing?  Is it a place I've disqualified for some reason [eg: pay is too low, looks like an HTML chop-shop, etc]?  What company is it for?  I end up doing the same sleuthing over and over again to find out it's either a job I've applied for, or a job I don't want to apply for.
Throughout this process, I've learned I much prefer responding to jobs that are listed on the company's own website.  And, I've also learned to copy and past parts of job descriptions into Google to find those original postings.
Anyway, HN, what's the best way to go about finding a job (besides direct referrals)?  And, why is this such a pain in the ass? <comment><USER2> There's one thing that's worked for me EVERY. SINGLE. TIME.

Dedicate yourself, but do it easily. Recruiters and HR employees get hundreds of applications for every job post. Make yourself stand out.

I do it with a website: <http://www.IHiredJeffClark.com>

For the low-level jobs I want, I just direct them there. It has examples of past work and recommendations pulled directly from my LinkedIn profile.

For the jobs that could be _The One_ (you know it when you see it), I create a specific subdomain for it. Then, I essentially write my cover letter on the website and include stuff relevant to that job (and the company) for them.

It proves what you can do and that you really want the job. 100% of the time, I get a callback.

<comment><USER3> Excellent. Can you show use one of your subdomains?

<comment><USER2> Sure:

<http://zipcar.ihiredjeffclark.com/>

[user and pass are both zipcar]

<comment><USER4> Did it work? what feedback did you get?

<comment><USER2> I get a callback 100% of the time I use a subdomain. Less so on the others, but still far above 75%.

</comment></comment></comment></comment></comment><comment><USER5> I've had a lot of success finding jobs online and landing subsequent interviews. Here's basically what I do:

* Use Google Reader to view RSS feeds for search results from SimplyHired, Indeed, HotJobs, Craigslist, LinkedIn, and Dice. Make sure your searches filter out recruiters and terms like CyberCoders.

* (Almost) Never apply to jobs via web form, especially through any 3rd party site. Strongly prefer postings with an email contact.

* Write a personalized cover letter for each position. Spend 10 minutes looking through their site and job posting, then craft your cover letter using their lingo.

* Use a spreadsheet to track your progress. This just keeps you on top of actually doing something. I prefer Google Spreadsheets b/c I can use it across multiple computers.

* Have a solid portfolio. Make sure it includes portfolio work, resume, and code samples.

* Send resumes in PDF, Word, and plain text. Each person has their own preference which is easy to accomodate.

</comment><comment><USER6> I think you're going about it all wrong. If a job is listed on a job aggregator website, I assume its garbage. Here's what I would do. Pick n (5? 10? 15?) companies you'd like to work for. Then research them all until you know everything about the company. Find out what their founder, CEO, designers are complaining about. Look over their website and find three or four problems.

E-mail them saying, "I'm interested in your company, and I'd love to work for you. In the mean time you can check me out here, here and here. I found x, y, z. Here's how I'd fix them. If you'd like to talk further I'm available on Skype, email, and my phone number is x. Call anytime."

<comment><AUTHOR> What makes you think _all_ job listings are garbage? I've found a few really promising ones. I imagine it's the same ratio that employers get when they receive tons of garbage resumes and a few gems here and there.

I like your proactive approach very much, but the search space (all companies in my region) seems rather large. With job listings, I at least know they are hiring, what technologies they use, and what's expected of the role. I'd be down to do it your way if there were an easy way to browse through interesting tech-related companies in NYC, that I know are hiring.

<comment><USER6> I look at it as how is my time best spent. I could send a default resume/cover letter to 100 companies in the time it takes me to send 2-3 well crafted cover letters to companies I'd actually like to work for.

It's the "Penis Craig's list Effect" (Credit: Ramit Sethi). Basically you can send a picture of your penis (resume) and sound like a desperate creeper(cover letter) to 100 women on crags list. Or you can figure out what you think 2-3 women actually want and write something specifically for them.

Funded tech companies probably won't pass up a proactive, solid programmer that shows some competency through a blog, side projects, weekend projects, etc, etc.

</comment></comment></comment><comment><USER7> If you're not already a web-based tool to store where you're at in which applications, start right away. Some people use Google Docs, others use <http://happyjobsearch.com/> (free) and some like <http://www.jibberjobber.com/> (freemium).

We built <http://linkup.com> for that very reason that people prefer and get better results applying straight to company's own websites. If you'd like to discuss it more, email me at email@example.com.

That biggest point that I wanted to talk about is "Have I already applied for this listing" problem. When sites talk about having 9M+ job openings in the US, that's because they show the same job opening multiple times. They have algorithms that take a job title, break it into chunks, and then remerge them in multiple methods. A good test is Microsoft - see how many jobs whatever site you're using has for openings at Microsoft - at any time Microsoft has around 2k openings, so if you see some multiple of that then something fishy is afoot.

Bluntly, it is a pain in the ass because the sites make money by having a huge number of repeat jobseekers continually visiting the site - who think that the site is 100% doing everything in the jobseekers best interest. But when you introduce a pay-per-post or pay-per-click model into the mix, delivering the best, purest jobs becomes contradictory to making a short-term profit. (Think early Excite.com vs Google.com)

</comment><comment><USER8> Assume a simple, powerful solution could be created that would organize your job search, and make it easy to track everything.

This solution costs $35/month. After you sign up, will you be paying by Visa, Paypal, or WePay?

See? I'm willing to bet you would avoid paying for this service even though organizing, executing and tracking your job search is a pain in the ass.

If you are ready to pay, let me know, and the minimum feature set will be ready by the end of the week.

hodgins dot dan at gmail dot com

<comment><AUTHOR> I would pay up to $100 for a website that had me take tests to prove that I'm not a crappy developer, and that had a reputation for uniting programming talent with awesome companies. I really wish something like this would exist, as I'm getting quite bored answering the sometimes-almost-insulting screening questions, and I'm absolutely certain companies are bored with asking them.

As per your offer, I probably wouldn't pay because I don't believe it's possible to offer such a service, without it missing some jobs I might really want, or without it not working. Some examples:

* Some jobs are exclusive to recruiters, and the only way to apply to them is through that agency.

* Duplicate jobs which have different descriptions. How could you handle that without making me think or do work?

* I don't believe you could offer better and/or wider reaching results than Indeed.com or other job search engines whose sole purpose is to find job postings.

* The job search market is already so full of middle-men that I don't trust half the posts and prefer applying to companies with job postings on their website, and via direct e-mail. In other words, you'd have to do a heck of a lot to earn my trust.

</comment></comment><comment><USER9> Job boards and craigslist suck just as much for employers as employees. Because the cost of applying is 0, people send their resume to every single job they can find. Its a chore to separate the wheat from the overwhelming amount of chaff.

So many companies recruit people directly instead. They'll use LinkedIn and github to identify people they want, and make direct offers. Sure, they might be overpaying for each employee, but its far more important that you hire great people than how much you pay them.

What I'm saying is don't expect much from job boards. You _might_ find something to pay the bills for now, but you're much better off spending your time putting code out into the wild and meeting like minded people. When you've done that, you'll be turning down job offers you didn't ask for. (BTW, "I can't market myself" is a cop out - we're all programmers, just show us some friggin' code).

Finally, where do you live? If you're in Raleigh or NYC, a good friend of mine is looking for top-notch developers with your skillset. Feel free to email me if interested.

</comment><comment><USER10> Where do you live?

A number of companies in and around SF have meetups and hacker events, and sponsor other groups. Go to hackathons at company offices, build something on top of their products, and then tell them you're interested in a job.

Engage companies on social networks, too. Tweet at the companies and their employees when you have interesting things to say, like blog posts you've written about your ideas for their products.

None of that addresses the organizational difficulty of a job search though. I usually prioritize and proceed in small batches. Just a few companies at a time, starting with the ones I'm most interested in. Assuming you have the luxury of time on your side.

</comment><comment><USER11> Welcome to the real world.

The last time, I communicated with an Internet Consulting Firm HR manager. He wasn't looking for a developer but for a copywriter, though, we have had some discussion.

I took a look on sample websites of the firm's portfolio. The design wasn't great and that were not so well crafted material. I got an eye on the source code and... the most terrible source I have ever seen. Imagine, links get opened by JavaScript code!!! Load jQuery and still use attachEvent instead of taking advantage of the jQuery library.

But I just can't tell that to the HR manager, he have long described to me that they have the most talented developers with over 5 years experience.

</comment><comment><USER12> It depends.

Do you have a solid resume? Do you know your stuff backwards and forwards? Are you willing to relocate pretty much anywhere for the right job? If so, pick the companies you'd _most_ like to work for (even if you think you'd never get hired there), and apply directly. If the company has a job listing on their website that matches well with your skill set, then all the better ( ex. [http://www.google.com/intl/en/jobs/uslocations/new- york/swe/...](http://www.google.com/intl/en/jobs/uslocations/new- york/swe/user-interface-software-engineer-new-york/index.html) )

If you're just starting out, or have a weak/varied work history, then your goal should be to end up somewhere where you can grow your skills, or where you can work your way into managing some larger projects. Even if the pay isn't great, or the commute sucks, a job can be worth if it fills some otherwise lacking spot in your resume.

Also, try to think outside the box. Do you have other bits of expertise in your background that might make you particularly attractive to a particular niche industry? i.e., if you know a bit about cars, then try to find a company that does something related to cars, and see if they have an internal development team. Often, domain-specific knowledge can make all the difference.

</comment><comment><USER13> I'm not sure there is a "best way" other than direct referrals, unfortunately. The problem is the the HR/recruitment industry is fundamentally broken. Jobs are inevitably farmed out to 3rd party recruiters who then sub-farm in the effort to make a split (commission) if their candidate is excepted.

This of course is a generalization but it is the root of the problem.

<comment><USER14> I don't think that HR/recruitment industry is fundamentally broken. It isn't optimal, but definitely not broken. Also, show me what industry where dealing with people is the core business is doing better?

I got all my best jobs through recruiters. Actually I even like dealing with them in general, they provide with tons of valuable info which you wouldn't know otherwise. As an added bonus they often amuse me when talking in a top- down way like 'get really prepared', ' this is a really good position for you', etc.

EDIT: I should have said that recruiters start talking to you nicely only after a certain point in your career. Till then, I guess, it can be a terrible experience and is better avoided by the means described in this thread

<comment><USER15> really? all my "good" experiences with recruiters were when I was younger, less experienced, and a little desperate.

They are just tops if you want to get into a company that doesn't know how to hire good people. My experience has been that if a company is going through a 3rd party recruiter, their standards are ridiculously low (and thus, I look like some kind of minor god) which is great if you are desperate for the cash, and eh, being the big fish can be fun some other times, too... but it's not how I want to spend my life, you know?

Working for companies like that gets old pretty fast, especially when they make you do interviews... you end up interviewing a bunch of people who aren't worth $15/hr for $100K/year sysadmin positions... It can be pretty frustrating.

I think the thing is that when given a choice, most people avoid recruiters. If nothing else, that's a nice big chunk of change that could have either been a bonus or salary for the employee, or some extra profit for the company. I hear 1/3rd of a year's salary is not unusual... which is pretty huge, really.

so when you go through recruiters, you are competing with people who don't really feel they have better options.

</comment></comment></comment><comment><USER16> I ran into the same problem last year and wound up building a personal search engine. It reads in listings from rss feeds and mailing lists and runs them through a simple ML classifier to filter out the dross. The classifier is seeded a list of keywords and then trained by feedback (thumbs up / thumbs down). It also doubled up nicely as an example project when I came to applying for jobs.

I've been thinking about adding a web interface and making it available to the public. Would anyone be interested in this sort of thing?

I have plenty more ideas for data sources eg follow links from HN and Reddit and crawl for links named jobs/careers. I could seed the classifier with content from uploaded resumes or from personal blogs. If enough people were to use it I could switch to collaborative filtering for the scoring. Imagine waking up to an RSS feed full of recommended positions based on the technology you write about in your blog and the code you upload to github.

</comment><comment><USER17> I've gotten more legitimate interest for positions from my LinkedIn profile and Github repos than I ever did in all the years using monster.com. One person even hit me up based on my about.me page.

The only stuff I get from the older job boards these days is cookie cutter emails from the same 15 outsourcing companies.

One bit of real advise I can give besides beefing up LinkedIn and Github presence is to become friends with a recruiter who you had a positive experience with in the past. Keep that person informed every time you even consider looking for something else. Make sure they know what your current skillsets and desires are. I have a two people that fit the bill that I always go to when I'm on the market and check in with regularly.

</comment><comment><USER18> Sounds to me like you've identified a potential opportunity! I recently went through a job search myself and while I didn't experience your exact pain points I definitely came away from the process thinking that there was room for improvement. I had an idea for a service that I wish I had during the process, I started hacking on it a bit but have yet to figure out a way to make it scale. I'm interested in chatting with you more about how the job search sucking might be remedied. Send me an email if you're interested (see profile).

</comment><comment><USER19> For the OP: is there were a website that could help you out, what would you look for? What could a web application do to help alleviate your problems?

</comment><comment><USER20> It's a pain in the ass because no-one is on your side.

If you could find a recruiter who got 20% of your signing bonus, it wouldn't be so bad.

</comment><comment><USER21> Look at websites of businesses in your area --- as well as their LinkedIn pages.

</comment><comment><USER22> You really want to prioritize embedding yourself in the industry, making a brand/name for yourself, and networking.

I'm not trying to sound like some kind of wanker, I'm a programmer too. My career never really got off the ground until I stopped settling for the retail-esque job search methods and got serious about socializing with smart people and building things.

Make something, slap your name on it, show it to HN. I doubt your job search productively consumes 16 hours a day.

Go to meetups for your various areas of expertise (PHP, JavaScript, Databases/MySQL), go to events/conferences, get involved in online communities, contribute patches, etc.

Stop being contented with the only part of your job search being submitting resumes. It's a fool's errand. Get people talking about you.

In my particular area of expertise, Alex Gaynor is something of a paragon of what I'm talking about. Look at how solid his career and reputation is, and how young he is. I doubt any programmer would be harmed by following his example.

Edit: I concur with Noahc wholly as well.

Edit2: Honest to god, if there's one thing I regret my father being unable to impart to me because of his blue-collar background, it's the nature of having a professional career and the necessity of networking/branding even as an individual. That said, I can change the hell out of the oil on my car.

<cato>

Further, I move that Alex should be working on the MongoDB backend for Django.

</cato>

<comment><AUTHOR> You don't sound like a wanker at all! That's all sound advice you've given.

The problem is that I'm very good at building things, but not so good at branding/marketing/selling them. It's my job to engineer things, not sell them. And, for some reason, I always feel uncomfortable selling _myself_. I don't really enjoy boasting.

Check out my profile. I've made things, I've shown them to HN. I built, probably, the most powerful bookmarklet to date. But the splash page sucks, and it's confusing, so I'm scrapping it. My website similarity search engine is doing pretty well, with traffic growing 15% a week for the last 7 weeks.

But, I don't have a personal website, or a blog, or a twitter account, etc. I don't care for starting flame wars about "Why you should[n't] do X" or "How I did some amazing thing in some short amount of time". It's really not my thing. While I completely agree it'd make it easier to get a job, and is probably the optimal approach, it's not an option right now. It would take a large amount of time to suddenly build a brand/identity.

On the other hand, optimizing my approach to the current systems of job postings is probably a better use of my time. This is the type of advice I'm looking for.

<comment><USER23> My solution for the last three or so years has been to maintain a personal site (<http://www.steveasleep.com/>) that consists of these things:

      * Links to and descriptions for relevant projects
      * List of recent blog posts (optional)
      * Latest 10 commits I have made to Github
      * HTML/PDF résumé
      * Links to my profiles on SO, HN, etc.

As a college student casting about for internships, that simple combination has helped me a lot. If you're interested, I could help set you up with the super-simple backend that can be hosted for free on App Engine.

I've also thought about adding a "hacker résumé" to supplement the regular one. The college job search format usually requires a conventional (boring) one-sheet résumé, but I would also like to provide a summary of hackerly accomplishments for the people I actually want reading my site.

<comment><USER24> Sounds like a steady setup. How packagable is it? With AppEngine, you could make this an easier transfer by consuming a short list of URLs in a textarea (homepage, resume, blogA, blogB, profileA, profileB) and simply spawn a clone.

Seen anything alse like it? I sort of asked here:

<http://news.ycombinator.com/item?id=1827294>

<comment><USER23> Very packageable, actually. Here it is on Github: <https://github.com/irskep/steveasleep>

It reads the sidebar from content/site.yaml. Sidebar items can point either to external links or refer to Markdown files also in content/ which are converted to HTML at request time. The only other remaining customization is to change the theme in content/templates/.

I like this instead of the feed-me-URLs setup because you can edit the Markdown and just hit Deploy in App Engine Launcher. Also, if I ever decide to move to App Engine, I have almost no barrier because I use the data store only for caching Posterous and Github information.

</comment></comment></comment></comment></comment><comment><USER25> I don't know. I've had great luck with craigslist for local jobs. For remote jobs nothing beats making physical connections, referrals are killer.

I recommend building a cool project preferably open source, to show off your skills and to set yourself from other candidates. You'll have employers coming after you.</comment>


Ask HN: What Is Your Blog? - <AUTHOR> Hello HN, I've been considering starting a blog, but realized I didn't know where to start. Wanted some inspiration so I thought I'd ask ya'll:
1. What is your blog about?
2. How often do you write on it?
3. Where do you host it (medium, substack, self-hosted, etc.) and why?
4. Link? <comment><USER2> 1\. Whatever I feel like writing about: largely rust, things I've enjoyed reading, opinions about work stuff, the occasional random other stuff, etc.

2\. Whenever I find the time, somewhere between a few times a week and twice a year, depending on lots of other circumstances.

3\. Self-hosted (via azure & cloudflare) HTML generated from markdown files using a fun little utility I built as a learning project (all the generator code, markdown, & HTML is stashed on GH: [https://github.com/mplanchard/speedy](https://github.com/mplanchard/speedy)). For whatever reason I'm more motivated to maintain something I've built myself as compared to previous attempts with medium and such. The freedom to do whatever I want, however I want is nice. I can present things simply, with little to no adornment, avoid pushing trackers and ads on people, explicitly release my content under whatever copyright I want, etc. So far I've yet to incur any costs beyond Azure's free plan, but while it's been free so far, I'd gladly pay a bit of money to continue to keep it under my control.

4\. [https://blog.mplanchard.com/](https://blog.mplanchard.com/)

<comment><USER3> > For whatever reason I'm more motivated to maintain something I've built > myself as compared to previous attempts with medium and such. The freedom to > do whatever I want, however I want is nice. I can present things simply, > with little to no adornment, avoid pushing trackers and ads on people, > explicitly release my content under whatever copyright I want, etc.

Totally agree. For my blog ([https://faical.dev](https://faical.dev)) I have a very similar setup (S3 & Cloudflare) with HTML generated from Markdown using a small command line tool I built ([https://github.com/ftchirou/article](https://github.com/ftchirou/article)). For publishing, I push a Markdown file to a repo and a Bitrise workflow takes care of generating the HTML and uploading to S3.

</comment></comment><comment><USER4> 1\. Mainly _computational and applied maths_ \- especially in the context of statistical sampling and computer graphics.

Some of my posts are detailed articles which, in my next life will evolve to journal papers, but most are just interesting things I have stumbled upon and explored, and then shared because I thought others might find them helpful and/or interesting, too.

2\. Sporadically, but about once a month.

3\. Wordpress. Why? I just downloaded some themes and a handful of plugins, and voila! I had a blog that is: well designed; has a responsive layout; elegantly displays math equations, and although 99% of the time has miniscule traffic, it copes well with occasional HN-induced traffic spikes. This means I can then set it and forget it, and focus more on writing.

4\. [http://extremelearning.com.au/](http://extremelearning.com.au/)

</comment><comment><USER5> 1\. Anything I google and don't find an obvious answer - reinforces the learning and may save someone else the effort! Also side project status updates as it's useful to look back and see progression

2\. Every few weeks? Not often enough!

3\. Self hosted with Ghost

4\. [https://blog.sixpoints.co.uk](https://blog.sixpoints.co.uk)

</comment><comment><USER6> 1\. I post my book notes and other things I'm learning about. I started it a year ago and I'm still trying to figure out what it's about.

2\. I post twice a week. I like the consistency and habit that regular posting imposes (I was posting 3x/week but found that was a bit too much).

3\. I use Digital Ocean to host. The blog uses Ghost CMS. I've used WP in the past, but I like the blogging focus and relative simplicity of Ghost. On the hosting side, I like Digital Ocean's pricing model, documentation and community. I'm starting a newsletter for the blog using substack mostly because it's dead simple to setup a newsletter with them. And rather than fiddle with various solutions, I wanted something turnkey that I could just get started with immediately.

4\. [https://mentalpivot.com](https://mentalpivot.com)

</comment><comment><USER7> 1\. Sensor readings, their applications, and electronics projects

2\. When I have an idea for an article and time to write it; average once every week to once every other week.

3\. Self-hosted, since I have full control over it, and it might draw attention to the items I'm selling.

4\. [https://www.anyleaf.org/blog](https://www.anyleaf.org/blog)

</comment><comment><USER8> 1\. I try to write about daily life although I am far to inconsistent for that to work, I am a bit better at writing short reviews of books I read. The goal is to use the blog as a practise area for general writing and reflections about what I read.

2\. Very inconsistently sometimes weekly and sometimes yearly... however as a target for the autumn I am aiming for monthly.

3\. Currently it's a hugo site on a S3,cloudfront stack however I am in the process of moving away from US owned services so it will be moved to another host shortly.

4\. [https://fredrikloch.me](https://fredrikloch.me)

</comment><comment><USER9> 1\. I write mostly about happenings in quantum information and quantum computing. Ranges between dives into interesting papers and commentary on recent funding/start-up developments.

2\. Whenever I feel inspired. Sometimes that means several posts within a week or two, sometimes it means months without posting. I realized I can't force myself to do it unless I've got something on my mind. I just can't write about something that I'm not obsessed with.

3\. I host it on netlify as a static site. Seemed easiest at the time.

4\. [https://whirlwind.netlify.app/](https://whirlwind.netlify.app/)

</comment><comment><USER10> 1\. I vlog about my 10 year perspective on maintaining and growing my software business (a web app marketplace I bootstrapped in 2010). Things like architecture, stability, performance,seo etc. I'm a strong believer in ignoring the fashions and searching for the timeless in software, and this is my attempt.

2\. Once a week at the moment. It's a lot of effort but I hope to monetize eventually (similar to railscasts or Laracasts).

3.Self-hosted (to avoid platform risk) plus YouTube (for organic inbound)

4\. [https://www.semicolonandsons.com/l/rails](https://www.semicolonandsons.com/l/rails)

</comment><comment><USER11> Great to hear. Everyone should write and publish online. Writing clarifies your thoughts. Publishing online allows you to receive feedback from others.

1\. Personal development and life updates, but I'm working towards writing market commentary. Took a step in that direction with my latest post.

2\. Once a week. It's a fairly tough publishing schedule though and longer essays take more than a week to write. I may rethink it in the future.

3\. Wordpress on Bluehost because it was easy when I started. I wouldn't recommend it though. Load times aren't great and changes are unwieldy.

4\. [https://jonathanliu.me](https://jonathanliu.me)

</comment><comment><USER12> 1\. Data science, mostly visualization, sometimes as fiction.

2\. Only a handful of times, over the past year. The time needed to write and edit can be long. I'm also trying to write a novel.

3\. Medium. I'm a writer for a publication called Nightingale.

4\. [https://medium.com/@PhilHawkinsDC](https://medium.com/@PhilHawkinsDC), my top article is this one: [https://medium.com/nightingale/draw-the-rest-of-the- chart-88...](https://medium.com/nightingale/draw-the-rest-of-the- chart-88eb0e8babd4)

</comment><comment><USER13> 1\. Mainly book summaries/notes/reviews. Planning to evolve it into full-scale compilatory essays. 2\. About once a week or once new material is available i.e. I've finished a new book. 3\. Github because I haven't gotten around to hosting it on a "real" domain yet. 4\. [https://skorbenko.github.io](https://skorbenko.github.io) PS. Any comments as per the improvement of content/styling/direction is welcome. You can comment here or shoot me an email through the form on the website.

</comment><comment><USER14> 1\. What is your blog about?

It's mostly about web programming and DevOps.

2\. How often do you write on it?

Not as often as I would like. Been very busy.

3\. Where do you host it (medium, substack, self-hosted, etc.) and why?

I actually just launched a new blogging platform at [https://www.dynablogger.com](https://www.dynablogger.com) so my blog is hosted there. It's a simple alternative to WordPress or Ghost. Check it out!

4\. Link? [https://vitobotta.com](https://vitobotta.com)

</comment><comment><USER15> 1\. Mostly self-promotional articles to lead towards my ebooks. But I'm proud of my 'customizing pandoc' and 'what next in Python' posts.

2\. I am averaging about 1 post per 2 months :(

3\. GitHub, because it is free and I can use markdown. Currently using a jekyll theme, but I'm planning to switch to static-site generator like [https://github.com/getzola/zola](https://github.com/getzola/zola)

4\. [https://learnbyexample.github.io/](https://learnbyexample.github.io/)

</comment><comment><USER16> 1\. I write about the more philosophical aspects of software engineering. As the years passed I got more interested in the "why". Why do we use certain techniques. Why do we build software the way we do. I started researching my questions and writing essays based on what I've found mixed with some of my own thoughts.

2\. I post twice a month.

3\. It's hosted on Netlify and built with Gatsby. All of my articles are just markdown files.

4\. [https://alexkondov.com/](https://alexkondov.com/)

</comment><comment><USER17> 1\. I write a mix between programming career advice and technical tutorials.

2\. I'm writing a book about career advice for programmers that will be published through Holloway early next year, so I don't post on my blog very often. I'm trying to write in the open at least once a month though.

3\. It's hosted on netlify because it's free. I use Hugo to generate the static site.

4\. [https://www.exponentialbackoff.com/](https://www.exponentialbackoff.com/)

</comment><comment><USER18> I write about ideas inspired from business,engineering and finance. I also share original thoughts of mine.

The goal is to enable my readers leverage these ideas for practical applications.

I currently release once a week on Sundays at 9am BST.

My newsletter is [https://leveragethoughts.substack.com/](https://leveragethoughts.substack.com/)

Check it out and please subscribe. It's growing and exciting.

</comment><comment><USER19> 1\. Anything and everything. It is often about my current research or an interesting tid-bit from math, philosophy, social sciences etc. It is more of a fluid knowledge base than a blog.

2\. I commit to the source code a couple times a week, but keep updating posts whenever I find time.

3\. I host the source code on Github and deploy on Netlify.

4\. [https://im.perhapsbay.es](https://im.perhapsbay.es)

</comment><comment><USER20> 1\. Fiji food recipes

2\. Once a week, videos as well

3\. Self hosted, Wordpress because its easier for my partner to use. Eventually want to do a flutter app for this.

4\. [https://thatfijitaste.com/](https://thatfijitaste.com/)

A nice way to preserve and document the uniqueness of Fijian/Fiji Indian food and something different to do apart from coding.

</comment><comment><USER21> 1\. Various topics, most often about electronics and software. I'm currently writing about a system for RF vector measurements I'm making.

2\. Around 1 post every 1 to 2 weeks.

3\. A self-hosted static-site generator I made myself 15 years ago.

4\. [https://www.tablix.org/~avian/blog/](https://www.tablix.org/~avian/blog/)

</comment><comment><USER22> 1\. My experience learning technology, notes on books that I read and everything related to self improvement.

2\. I have a reminder for every friday so yes, mostly 1 post weekly which is what I try to keep up to.

3\. Github, because I wanted to learn github pages and also design a simple blog myself.

4\. [http://codingbbq.github.io](http://codingbbq.github.io)

</comment><comment><USER23> 1\. WordPress and Laravel tips that we've learned through doing client work as well as case studies for clients

2\. I would say we average once a month or so.

3\. Self-hosted WordPress. It's what we're familiar with and we can customize it easily if needed.

4\. [https://alphaparticle.com/blog/](https://alphaparticle.com/blog/)

</comment><comment><USER24> 1\. Streaming, server-side media processing, graphics, networking and all things related. These are things that interest me and I'm sure there are my soulmates out there with similar interests.

2\. I just recently started.

3\. Hosted on Netlify, built with Hugo.

4\. [https://ivarsblog.com](https://ivarsblog.com)

</comment><comment><USER25> My blog is about field stories on product and engineering : [https://amols.blog](https://amols.blog)

I started recently. So just once a week, I publish. Writing happens whenever I find a topic worth organising or sharing

Netlify. It's free. I use gatsby theme borrowed from Victor Zhou

</comment><comment><USER26> 1\. 'Random' as I develop a new direction.

2\. Aiming for twice-weekly.

3\. Regular web host w/WP. In the interest of 'stop playing around with tools/static sites and just write'.

4\. [https://jamesgill.net/articles/](https://jamesgill.net/articles/)

</comment><comment><USER27> 1\. I mainly write about what I work on day-to-day. At the moment, that's using React as a frontend developer.

2\. Weekly, I aim to ship by Tuesday evening (Australian time)

3\. Self-hosted on AWS S3, with a Cloudfront CDN.

4\. [https://maxrozen.com](https://maxrozen.com)

</comment><comment><USER28> 1\. Software engineering in general. Topics I get in contact with and think about. A lot of it gets a bit philosphical because I don't have clear answers.

2\. Maybe once a month

3\. Self hosted. Got a server anyway, so I can as well host it myself.

4\. [https://stefanschick.eu](https://stefanschick.eu)

</comment><comment><USER29> 1\. Technical topics that strike my interest. Thinking of expanding it to include other things I'm interested in.

2\. Not enough.

3\. Gastby.js and Netlify because it was easy to get started with.

4\. [http://carlchesterlloyd.com/](http://carlchesterlloyd.com/)

</comment><comment><USER30> 1\. Security, privacy, software development, music, random goings on...

2\. From a couple times a week to every other month.

3\. Self-hosted because of development-ease and customizability.

4\. [https://www.eivindarvesen.com](https://www.eivindarvesen.com)

</comment><comment><USER31> 1\. My personal public diary 2\. Very rare 3\. Self-hosted and built on wordpress 4\. [https://www.aayushaggarwal.com](https://www.aayushaggarwal.com)

</comment><comment><USER32> 1\. Productized services.

2\. Haven't updated it in a while but used to be every week

3\. Self-hosted, because I wanted custom features (community)

4\. [https://www.productizedstartups.com](https://www.productizedstartups.com)

</comment><comment><USER33> 1\. Random thoughts and things I find 2\. At least once a week 3\. self hosted with ghost 4\. [https://www.michael1e.com/](https://www.michael1e.com/)

</comment><comment><USER34> 1\. Technologies & lifestyle decisions

2\. Sporadically, 1x a month on average

3\. AWS S3 + Cloudfront, to control recurring costs and support spikey traffic

4\. [https://maxmautner.com](https://maxmautner.com)

</comment><comment><USER35> With everyone writing blogs do people actually read them or are they more like a public diary

</comment><comment><USER36> 1\. I'm writing about all startups we are working on.

2\. Whenever feel inspired & have a time. But trying to do this

once a week.

3\. self-hosted. want to rise own traffic.

4\. [http://urlaunched.com/blog](http://urlaunched.com/blog)</comment>


Women Founders – Discord community for startup discussions - <AUTHOR> https://discordapp.com/invite/4MgYumc <comment><AUTHOR> I'm a co-founder of kosmos school (educational VR games) and froggodoggo (side-gig platform for founders). I would love to have a very informal place to talk to other women (or else, see below) about startup-stuff, discuss what we are working on, motivate and help each other... that's why I just opened this server.

Note: Even if it says "women" in the name, it doesn't exclude men, trans or non-binary folks, everyone welcome as long as it stays friendly, safe and inclusive :)</comment>


Ask HN: Why knowledge is not centralized? - <AUTHOR> The flood of articles every minute can't be a healthy way to acquire knowledge. Should we have organized knowledge bases and we consume it step by step? <comment><USER2> What is your question? You are currently in charge of your knowledge consumption. What is preventing you from building a personal knowledge base?

I'm currently trying various tools for managing information and plan to build something custom for myself. The current tools I'm using are raindrop.io (bookmarking/searching), notion.so (note taking), keybase (file sharing/note taking), and maybe one more but I'm forgetting.

There are tools to manage your consumption and knowledge habits if you look for them and none of them require a centralized knowledge base.

<comment><AUTHOR> Nothing prevents me, but why we don't recognize this as a problem? Shouldn't it be the default way for publishing and storing knowledge?

<comment><USER2> If nothing is preventing you from building a personal one then nothing is preventing you from building a centralized one. All you have to do is convince enough people to use it.

Google is essentially a centralized knowledge base. So centralized knowledge bases already exist and they're called search engines. There are also free blogging services that publish everything on the web to be indexed by Google. Blogger is even owned by Google.

</comment></comment></comment><comment><USER3> Who will be in charge? Imagine something like Wikipedia or Stack Overflow. They work but they are not perfect. (Or in the other extreme 4chan and Yahoo Answers)

<comment><USER4> Or google where certain topics are forbidden and they will even delete personal files that mention them. Perhaps that time AOL deleted all the Breast Cancer Awareness material because they simply did a search and delete on some word?

And that was nothing compared to the work of Stalin or the North Korean government.

Think Ministry of Truth.</comment></comment>


Distributed Version Control is here to stay, baby - <AUTHOR> http://www.joelonsoftware.com/items/2010/03/17.html <comment><USER2> "If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics."

This is great. A few years ago, DVCS was weird and strange and SVN was the stuff. When people discover how awesome Git and Mercurial are, they stab SVN/CVS in the back.

<comment><USER3> That's just life in technology as the tools improve.

1) Stop manually backing up versions, that's error-prone. Use RCS!

2) Stop using RCS, it doesn't scale. Use CVS!

3) Stop using CVS, it's too complicated. Use SVN!

4) Stop using SVN, it makes it hard to merge branches. Use Hg/GIT!

... And someday, we'll be saying 5) Stop using Hg/GIT. They ________. Use _______!

Same thing for hardware, and languages, and frameworks... and just about everything. _shrug_

<comment><USER4> It's funny how it's usually easier to ditch X, and write Y from scratch, rather than try to improve X.

<comment><USER5> I agree and don't think it's limited to programming. Considering business, it's difficult for a large established organization to make drastic changes.

It's much easier for a new entrant (startups) to innovate because they don't have the same baggage.

<comment><USER6> Yes, where by "baggage" you mean "vitally important existing customers, users, and dependencies that will break if you change anything".

<comment><USER5> Yes, I do.

But that doesn't change my statement.

If you're not willing to break your business to change with the times, someone else will--and by the time you react it's too late.

</comment></comment></comment></comment></comment></comment><comment><USER7> But _how_ does thinking about changes rather than versions make things easier, Joel? You never quite explain...

<comment><USER4> A version is just a changeset, so for me, it makes little sense to claim "changes" are a completely different way of thinking than "versions".

Perhaps it comes down to how you divide work up. I just don't like branches. They're mess.

<comment><USER8> I don't like branches either (we've been using git for maybe a year now at justin.tv, so I've definitely had the opportunity to grow to like them).

Actually I think one of the biggest reasons I don't like them is that they're a kind of "hidden state". If someone made a VCS (or just an _interface_ to an existing VCS) where branches were just represented by different subdirectories in the filesystem, then I might use them more.

<comment><USER9> That _is_ how branching works in svn, you make a copy to another directory on the repository.

<comment><USER8> I know how svn branching works - I don't think I explained myself clearly.

I'd love a RCS that would let me see every branch that currently exists _without having to check them out_. The branches would exist as directories on my _local_ filesystem. Any file operations (doing a directory listing, or accessing a file) on these local directories would actually be doing RCS commands and pulling data over the network, but I wouldn't have to think about that anymore.

<comment><USER9> If you checkout the svn root, you get all the branches as directories in your local filesystem. After that, it seems it would be the same as what you're saying.

Besides, you can do svn ls to see the branches.

I must be missing what you're getting at.

<comment><USER10> I think he means that the way you work is the same as in SVN but the way the system works is like Git etc.: the branches are editable and accessible like directories but with the advantages and changeset-construction of Git behind it.

Am I right?

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> "The interesting part is that these systems think in terms of changes, not in terms of versions."

Not git. Git's repository model is very strongly snapshot-oriented. Of course the whole machinery for supporting changesets exists in git, but it is built atop a system that actively avoids "thinking" in terms of changes.

Linus on this: [http://marc.info/?l=linux- kernel&m=111314792424707](http://marc.info/?l=linux-kernel&m=111314792424707)

<comment><USER12> I don't think that link contradicts Joel. Git represents repositories as a network of diffs, not a linear history of versions.

<comment><USER11> This is not true for git's object model (which I believe maps to Joel's "user model".) Quote The Git Book:

 _"Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage systems - they store the differences between one commit and the next. Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git."_

Source:<http://book.git-scm.com/1_the_git_object_model.html>

However the diffs are there below the snapshot-based model as means of effectively storing and transmitting the snapshots.

<comment><USER13> Conceptually git thinks about snapshots of trees. The pack format uses deltas but that's a mostly hidden detail. The pack format didn't exist for the first months of git's existence.

I haven't bothered to read the blog post (Joel strikes me as someone with a huge ego and without any exceptional insights), but doesn't the above fact mostly refute his thesis? I like git and hg but they are just tools. You could do the same development model with patches.

</comment></comment></comment></comment><comment><USER14> "we developed a new way of developing software using if statements instead of branches." Is that critizing feature flags? Or is more to that?

<comment><USER4> It often makes sense to have 2 alternate implementations of a component in the same codebase, so you can switch between them at startup/during runtime, and compare them side by side. Something that isn't as easy to do if you create 2 separate branches.

<comment><USER15> I think a better solution is to have both features in branches, and have a 3rd branch which allows realtime switching between the 2.

a nice upside is that you can merge changes to each feature up into the "combined" branch as they get stable, to test side by side. when you finally finish, you can leave feature a behind by merging b into your release, or vice versa. or maybe even merge both into mainline.

sorry, the point I was trying to make is that cheap branching and merging is still an easier way to manage this situation than just ignoring branches altogether.

<comment><USER4> In what way easier?

A: Create separate branches, manage merging/updating unrelated changesets.

B: Create 2 implementations of something in code, and manage nothing.

I guess it depends on how easy it is to isolate the part you want to create 2 implementations of, so it may depend on what language you're using as well as how you architected things.

Branching+Merging just seems like something extra I have to do, manage, and remember. Like filing. And I still can't see what benefit it gives for many cases.

But that's fine I think... I just don't get it. Maybe I'm too old ;)

</comment></comment></comment></comment><comment><USER16> It helped me to think about it in terms of connected graphs. Nodes are versions and arcs are changes. A path between two versions is the aggregation of changes. Merging then becomes walking down the same path, but starting from a different node. I start at my current version node, and I walk down your path of changes. It's very different than trying to merge two nodes.

(This is just my mental model, no need to read into it more than that)

</comment><comment><USER17> So is Joel's blog apparently.

<comment><USER18> He implies in the last paragraph that it's his final post. Still, I think there's a point here. Writing, when you're that good at it, isn't so easy to give up. Also, the blog has been a huge part of Spolsky's success. So I bet he'll revive or continue it in some form before too long.

Edit: I hope he does, too. I probably disagree with him more than half the time, but there are few other writers on software who consistently hold my attention, and almost no one who consistently makes me laugh.

<comment><USER19> I would be happy to seem him move to a more personal blog. Something that is a little more about his personal experiences with technology. It sounded like he didn't like the regularly-published business-oriented posts.

I wouldn't mind a picture of Taco on each post.

</comment></comment></comment><comment><USER20> I've only lived through one version control migration, that was from TFS to Subversion. The problem we have is the length of time Subversion takes doing updates, commits, and merges when you are dealing with a large repository and many changes spread out among files. (Good old TFS was fast.)

Can anyone say if Mercurial is significantly faster?

After going through Joel's tutorial it looks like Mercurial keeps history from branches in the root much better than either TFS or Subversion. I think I would opt for Mercurial the next time I have to set up source control.

<comment><USER21> I can say without hesitation mercurial or git will be _insanely_ faster for these operations. Remember, you work locally, and then push with hg/git. So when you do "git commit" it only relies on the speed of your hard drive/cpu. Commits happen instantly. Updates are needed very rarely (since you don't need to update to make new commits). Merges are so much faster it's not even funny. After merging in hg/git you wonder why SVN even had a merge functionality.

In addition to those conceptual differences, the actual act of transferring files between remote and local on git/hg is also _much_ faster than SVN. Entire checkouts of git repositories are usually smaller (disk size) than the equivalent SVN checkout... of one version. This means less time on the network all around.

<comment><USER20> Yeah, committing to your local copy better be fast, it's committing to the shared server repository that I'm concerned about.

<comment><USER22> I think you'll find that whatever git does, it's faster than the corresponding operation in SVN.

When you send commits to a remote server, git compresses them and sends the packfile over the network. The server will refuse non-fast forward merges (the branch you're pushing is supposed to be merged by you first, locally) so it pretty much has nothing to do but uncompress the changes and apply them. Unless you have a really slow network or are sending an insane number of commits, it's not going to take longer than a few seconds.

Cloning big repositories (like emacs, with ~25 years of history) can take a while if you have a slow network, but sometimes it feels like git can actually clone a repository faster than SVN can check out a single revision.

But repos like emacs' are rare. Often, SVN repositories end up being huge because they contain the code of many unrelated projects. In Git, having such a huge repository is impractical; each project should have its own repository. There is support for submodules though, so you can make a "master" repo that contains pointers to the child repositories, if you really have to.

</comment></comment></comment></comment><comment><USER23> There's something bothering me about the hosannas to the power of merging changes. Isn't there an unspoken assumption that all your work is text files ?

If we talk drawings, photos, whatever binary data is needed for a project - what happens ? Are the binary deltas as good as SVN's ?

Even if the "binaries" are XML text - e.g. drawings in SVG - wouldn't I be out of luck trying to merge changes if 'Beth' added a squiggle and 'Cath' a square to different parts of the drawing ? (many tools, upon writing, reorder data 'ad lib'). Are there "merge tool" plug-ins ?

<comment><USER24> Binaries are not merged - if histories diverge and one side changes but the other does not, it will choose the side that changes. If both sides change, it will record a conflict and you have to choose one side (or create a new binary that you tell the system is resolved). You can run an external merge tool with 'git mergetool' and there are over a dozen it knows how to run, but I don't know which of them will handle images. You can also use .gitattributes to help you diff binary files efficiently, but you still have to either choose one side or manually create a new binary. I mean, even a merge tool won't help much there - if you have images that changed on two different branches and you want to combine them, you have to fire up Photoshop or something anyways - that's almost always going to be a manual process. Though, in the four or so years I've been using Git (and the years before that with SVN and CVS and RCS) I don't remember having to do that very often - thus is the life of a coder, I suppose. The people who create and modify images for programs tend not to tread on each other.

Also, this is really the same problem even for systems without solid branching capability, like SVN. If two people modify a binary image at the same time and one commits, then the other will get a merge conflict when they update and will have to solve the conflict in order to commit.

</comment></comment><comment><USER25> Blogging is hard to give up, Joel?

Edit: Uh stop upvoting me please. That was a tongue-in-cheek comment and, as sant0sk1 pointed out below, also lazy on my part.

<comment><USER26> Not at all! Today is the ten-year anniversary of my first real post, so I've been planning to have my last real post on 3/18 for a long time.

Thanks for all your attention over the years. I'll still be around, just not doing these essays any more.

<comment><USER27> btw, Kiln looks really cool, especially the visual code tree. Your interns deserve a pat on the back for that.

<comment><USER28> Are you referring to this?:

[http://www.fogcreek.com/Kiln/learnmore.html#hist_BranchAndMe...](http://www.fogcreek.com/Kiln/learnmore.html#hist_BranchAndMerge)

That's about standard, the free 'gitk' does that much, too, for git.

</comment></comment></comment></comment><comment><USER29> For me, it always has been and always will be a right tool for the job issue.

We work on relatively small code bases with a very small team of people, not large, unwieldy open-source projects with hundreds of contributors. Primary interest is in a log of what has happened to the code chronologically, rather than applying/unapplying specific revisions/hunks frequently. No need whatsoever for people to run with their own branches. With those requirements, git, Hg or Darcs would all present far, far more headache than they're worth versus Subversion.

In some other scenarios, the formula may yield a different outcome...

</comment><comment><USER30> That backpack anecdote is a play straight out of Guy Kawasaki's _The Macintosh Way_ ([http://www.amazon.com/MacIntosh-Way-Guy- Kawasaki/dp/00609733...](http://www.amazon.com/MacIntosh-Way-Guy- Kawasaki/dp/0060973382/ref=sr_1_1?ie=UTF8&s=books&qid=1268951347&sr=8-1)), which is on Joel's recommended reading list for managers ([http://www.joelonsoftware.com/articles/FogCreekMBACurriculum...](http://www.joelonsoftware.com/articles/FogCreekMBACurriculum.html)).

</comment><comment><USER31> What an excellent way to go out. Great last article Joel.

</comment><comment><USER32> It's a DAG. The arcs are diffs (edits).

</comment><comment><USER33> What's wrong with a jalapeño bagel?

</comment><comment><USER34> How this article got so much points I'll never know. Its some novice advice on version control. Why don't you read the git books, they'll tell you all about it in well-organized fashion: <http://book.git-scm.com>

<comment><USER34> Agree: Upvote, Disagree: Downvote. _That_ shouldn't be the way to go. I insist the article is novice advice. At least take the time to reply on how you find it original rather than simply downvote.</comment></comment>


Matz: I use Debian, I have no Ruby problems. - <AUTHOR> http://www.ruby-forum.com/topic/785744#971922 <comment><USER2> It's great that manual compilation works for Matz. And his great work notwithstanding, it has little to do with the general user.

As an occasional Ruby programmer, and frequent Ruby-based utility user, I do not want to compile and install Ruby or Ruby modules myself. If we go down that road, why don't we compile everything from Python to GStreamer ourselves (since they all have modules/plugins/...)?

To the general user (as opposed to full-time Ruby programmer), Ruby and Ruby modules are just dependencies to the application they want to use, and installation should be automatic. One can only hope that the Ruby community understands this, and makes it easy for distributors to package their software.

<comment><USER3> Have you tried rvm?

      bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )
      rvm install 1.9.2
      rvm use 1.9.2 --default
      which ruby

EDIT thanks telemachos, add this to either zshrc (if you're using zsh) or bash_profile or equivalent

      [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"

<comment><USER4> Are you seriously suggesting using a a package system that is bootstrapped by downloading and running a shell script with no security protections whatsoever?

Moreover, it's not just you giving a bad example, as the shell script then clones a git repository, again with no protections whatsover (over http by default to make it really easy to MITM attack), and runs code from _it_. So this was written by people who just don't care, or don't understand security. Not people I'd be trusting with package management on my system.

This kind of thing might have been acceptible, barely, before 1995. Since then, we've developed package systems with gpg signed chains of trust.

<comment><AUTHOR> I think you're being _just a bit_ reactionary.

Besides if you git clone, literally _every commit_ is checksummed. I'm no security expert, but I don't think MITM-ing a 'git clone' sounds 'really easy.'

<comment><USER5> No, you're clearly not a security expert. If you're doing a git clone over HTTP, you can't even be certain you're talking to the right git repository. Sure, each and every commit may be checksummed, but how exactly do you anticipate knowing what the correct checksums are?

<comment><AUTHOR> Fair enough. Like I said, I don't know enough about this.

> how exactly do you anticipate knowing what the correct checksums are?

Well, because the repo you're cloning knows what they are... I wasn't thinking about the repo itself being owned, but git's whole job is to make sure that chunks of text get from one place to the other in an identical state, so...

<comment><USER6> The target repo itself isn't owned, but your connection is. The point is that you only _think_ that you are talking to the correct repo, when in fact you are cloning whatever git repository the attacker would like you to.

It's obviously a focused attack as are all MITM attacks, so you can assume the attacker is familiar with the install script. So when the script then continues and performs it's next action on the contents of the repository, you will execute an arbitrary payload.

Edit: It wasn't clear to me that the problem had become apparent in the parent post. Probably just pre-coffee thinking on my part, but hopefully this will help clarify it for anyone else reading along who also missed it.

<comment><AUTHOR> Yes, when I said 'the remote repo', what I meant was 'the one that I see.

Thanks for the extra explanation, guys! Makes a lot of sense.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Assuming this is a response to yesterday's news about Debian's Ruby maintainer, I don't see how it's relevant. Matz is almost certainly compiling his own Ruby (as many Rubyists do) and not using the Debian packages for Ruby.

<comment><AUTHOR> It's true. I mostly just thought that it was interesting that after reading all that hubbub over the last few days, to pop open ruby-talk and see this...

At the same time, there is a certain amount of relevance: while lots of Rubyists (including myself) talk a lot of shit on Debian, Debian is still the only Linux that is (technically) supported by Ruby. It's this way because the Hudson (or whatever, it's still early...) server is running Debian, and they don't have another box or two... but still, I guess my point is that Debian is important, no matter how frustrating their policies may seem at times.

</comment></comment><comment><USER8> I'm seeing a trend in the comments re RVM and other suggestions.

There are essentially two issues at hand here and we would all do well to remember the difference between the two.

1\. Ruby as a good citizen in a distro 2\. Ruby as a development tool for programmers

#2 is mainly achieved via RVM for sure. I program both Ruby and Python and as well as some JS and Erlang. I LOVE RVM for ruby/gem management and actually prefer it to Python's virtualenv (just a preference! Don't bite my head off ;) )

#1, however, is what we should really be talking about as it is what the original debian maintainer was complaining about. Matz is more talking about #2.

I use Ubuntu as my development and deployment platform. I could never imagine if Python was not available, stable and usable as a base package on Ubuntu without me having to do some RVM/Virtualenv incantation each time. Sure, there could be a chef/puppet/script installation approach, but why? And for those who think this is trivial, think about all the packages that are in fact written in Python that are part of the desktop or base system. Python is literally embedded in everything!

One of the greatest things about Debian/Ubuntu, and why I think it is the premier development platform, are things like: sudo aptitude install build- essential

All that being said, this is a very hard problem to generally solve. I would hope that Ruby would be more Pythonic in the distro, but I don't see it being a priority for Ruby folks anytime soon....

Side note: go look up the transition from Python2.6 to Python2.7 for upcoming Ubuntu 11.04 to see what is involved in such a transition. It is non-trivial to say the least but Debian/Ubuntu maintainers are doing a stellar job with it...it is a complex issue and much care is needed...

And as another aside...anyone remember the Ubuntu rolling releases issue? At is core with rolling releases was things like Python2.6 -> Python2.7 transition...not something you can easily achieve in true distro rolling releases and again, just an example of why this is a complex problem and things like RVM are not appropriate for discussion of #2 as it stands.

<comment><USER9> I agree with much of what you say about the two different threads and perspectives here (and elsewhere) whenever this argument comes up. However:

> And for those who think this is trivial, think about all the packages that > are in fact written in Python that are part of the desktop or base system. > Python is literally embedded in everything! [...then later...] All that > being said, this is a very hard problem to generally solve. I would hope > that Ruby would be more Pythonic in the distro, but I don't see it being a > priority for Ruby folks anytime soon....

You say that Ruby should be more Pythonic and that this is not a priority for "Ruby folks", but I'm not sure that's a fair way to characterize the distro problem. In fact, from Ruby's point of view, Debian has a special pride of place: it's the _only_ officially supported Linux distro (since testing is done on Debian machines, I believe). For more on that see the discussion and links in this thread: <http://news.ycombinator.com/item?id=1614618> (tenderlove is Aaron Patterson, a Ruby core dev).

I would argue, as I say elsewhere in this thread, that the reason Python is so well handled is precisely what you mention in the first bit I quote. _Because_ so much of the Gnome desktop is written in Python, perhaps Python gets special treatment by the distro. That suggests that the distro needs to meet the language devs at least part way, rather than that the language folks are the only ones who need to change their attitude.

</comment></comment><comment><USER10> Matz compiles. He doesn't use Debian's packaging.

<comment><USER11> He most certainly uses Debian's packaging for any dependencies he may need.

Or do you think he also compiles stuff like Readline, IConv, Zlib, OpenSSL? Or stuff related to Ruby gems, like postgresql-server-8.4, in case he needs ruby- pg ?

On other platforms even installing GCC is a painful process, when on Debian/Ubuntu is as easy as:

          sudo aptitude install build-essential

And why would he need to compile his own Ruby for stuff unrelated to developing the Ruby interpreter? Are you telling me that if he needs to do some quick processing on some machine he absolutely needs HEAD?

<comment><USER10> The backdrop on this topic is the recent news of Debian's Ruby package maintainer quitting, mostly due to issues he has with the Ruby core community and the maintenance/release process.

This post by Matz was supposedly submitted to debunk the myth that "Ruby's not for Debian", but it is entirely orthogonal to the issue at hand. Matz undoubtedly compiles his Ruby, as most maintainers would do with their projects, rather than install using Debian's package manager.

<comment><AUTHOR> If you look at the topic of the thread, it's to a user. The ruby-talk mailing list is for general discussion, and the title of the thread is "Best Linux Distro for Ruby?"

</comment></comment></comment></comment><comment><USER12> I just don't get why this is supposedly a Ruby problem rather than a $LANG problem, when Lucas Nussbaum's complaints about Ruby's packaging situation (sans the whining about Japanese) apply equally well to every other language you might want to install.

It's also pretty hilarious when a guy maintaining one of 50+ different distributions of the same software cries about division of manpower upstream.

</comment><comment><USER13> A tautology, no? He wouldn't use Debian if he did have problems.

I get neck deep in large Ruby deployments and the issue is clear to me. Ruby is evolving at a breakneck speed but as a result has very poor release management.

My solution:

Use Bash and Python for systems programming. Both are stable and simple well integrated into Ubuntu and frankly much better for the task anyway. Oh no, now I can't use Chef! (sarcasm)

Use Ruby for web development, with RVM and bundler. This is a vast universe of bleeding edge web programming toys.

I struggle to see a real problem here...

<comment><USER14> " Ruby is evolving at a breakneck speed but as a result has very poor release management."

Just what is changing so fast in Ruby? Is 1.9.2 so much different from 1.9.1? Has anything changed in 1.8.7?

<comment><AUTHOR> 1.9.1 -> 1.9.2 changed the way threads were handled, which was pretty huge. And good for Ruby.

<comment><USER14> Ah, OK, thanks.

Still, does this count as "breakneck" change?

I'm not seeing it, but maybe I'm too close to the subject matter.

</comment></comment></comment></comment><comment><USER15> Who is matz? Everyone seems to know..

<comment><USER8> The guy who wrote Ruby - <http://en.wikipedia.org/wiki/Yukihiro_Matsumoto>

<comment><USER15> Ahhh, ok. Somehow the only japanese i know is the creator of Mario :p Thanks, anyway.

I can't imagine, i'm the only one, who didn't know.</comment></comment></comment>


U.S. employees set to be forced to give bosses their Facebook PASSWORDS - <AUTHOR> http://www.dailymail.co.uk/news/article-2313367/CISPA-Amendment-US-cyber-attack-law-banning-employers-asking-Facebook-passwords-blocked.html

<comment><USER2> This is an old controversy. If you are an employer that does this, you could face legal action from Facebook's legal team.

"by engaging policymakers or, where appropriate, by initiating legal action, including by shutting down applications that abuse their privileges."

[http://www.facebook.com/notes/facebook-and- privacy/protectin...](http://www.facebook.com/notes/facebook-and- privacy/protecting-your-passwords-and-your-privacy/326598317390057)

I was really happy that Facebook came out with that. I don't think the policy will change even with the next CISPA-like thing going on.</comment>


Data is the Public Good. Data is the Infrastructure. Data is the Stimulus. - <AUTHOR> http://blog.fortiusone.com/2009/01/28/data-is-the-public-good-data-is-the-infrastructure-data-is-the-stimulus/

<comment><USER2> Data is my beach house, data is my hometown. Data is my king size bed, data's where I meet my friends. Data is my hot hot bath, data is my hot hot sex. Data is my backrub, data is where I'd like you to touch.</comment>