Ask HN: Raw SQL vs. ORM? - <AUTHOR> What's your opinion/experience on using raw SQL queries vs using an ORM for interfacing with an SQL DB? <comment><USER3> The trade-off is that of every higher-level VS lower-level anything when it comes to computers:

Higher-level: Dependent on the quality of the "bridge", but generally you will benefit from good-practice security measures, less repetition and more idiomatic code with regard to your language of choice. What you lose is the cost of the bridge and the fact that the bridge itself has to be maintained over time, requiring you to keep up with any API changes.

Lower-level: Generally less approachable for beginners, highly dependent on your capacity to understand all the implications of the choices you will make, will yield more performance if used correctly because the layer between you and the system is smaller but with power comes responsability.

<comment><USER4> > good-practice security measures

+1 for that. Even for super small projects, I use an ORM, because there is always some user input that needs to go to the database query string. Life is too short to maintain every single query.

<comment><USER5> I would like to add that this is not a binary choice. Depending on the complexity of the requirements its possible to differentiate between and even mix the levels of abstraction.

I personally like to avoid using ORM by its true meaning (mapping object and relational models) but I like using certain facilities an ORM library might provide, such as session management, user input validation, etc.

</comment></comment></comment><comment><USER6> Short answer: First one, then the other.

A good ORM that abstracts away simple access, querying and database creation can be a godsend during many early iterations of a project.

Eventually however you may start to hit boundary cases where an ORM is unsuited or generates slow queries. Once you identify slow queries, then drop down to raw SQL to optimize only when you know where to optimize.

<comment><USER7> This is my answer as well (mostly). Earlier in development when you are iterating on your data model and just trying to write a lot of code, an ORM can help move things along quicker.

But once your project is more established, well designed tables and well written SQL could have large impact on performance.

</comment></comment><comment><USER8> Raw SQL is always better, IMHO.

There are no new abstractions (for example extra session/trransaction-like behaviour).

You can write good efficient SQL and not use an iteration-protocol.

ORMs tend to make slow and clumsy SQL. It might not matter if you only update one record, but if you need to fix something in 1 billion records, you are going to feel the pain..

If you need to learn real sql (and not clumsy beginner-sql), look at use-the- index-luke.com and modern-sql.com (both from the same, fantastic knowlegdeable guy) and read Joe Celkos "smarties" books...

If needed, a small library can help write CRUD style SQL. I have implemented them myself multiple times in an afternoon. Only tricky thing.. Handling of strings so that you have no SQL-injection.. (for that, serverside bind- parameters are a god-given).

<comment><USER9> I have had a number of contracts where my entire job was to fix the performance problems introduced by using a ORM. ORMs add a layer of complexity to your code and a huge risk of really bad SQL.

<comment><USER10> ORMs can be used poorly sure, but anything I can design using raw SQL I can typically do with an ORM. The question is, are people using ORMs as a way to avoid having to figure out proper database design? If so, they should not be using an ORM and should _really_ learn how the database they will be using works. Heck! There's micro ORMs like Dapper which let you run raw SQL and match it to an actual object for you, to be fair almost all ORM's support doing raw SQL and getting back an object which can be handy for performance bottlenecks. Badly coded software will usually have performance issues, whether using raw SQL or not.

Update: Fixed typos.

</comment></comment></comment><comment><USER11> Raw SQL queries will perform fast if you write correctly. No ORM will stand close. Stored procedures help a lot. It's close to C/C++ in a sense that is easy to shoot yourself in the foot.

On other hand, ORM helps to write code that can be unit tested and you can test that some data retrieval conforms to certain principles.

<comment><USER12> Hand-written SQL is not intrinsically faster than ORM generated SQL. The instances where ORM's have worse performance is typically due to application errors like n+1 queries or forgetting to batch updates. If you actually know what you are doing you can typically do the same optimization on the ORM level.

</comment></comment><comment><USER13> Use an ORM.

Use an industry-standard ORM -- Hibernate, ActiveRecord, SQLAlchemy, whatever is the done thing in your language.

There's just no reason not to. Onboarding new developers becomes easier. Your common queries (fetch a record by PK, fetch some associated records by their FK, etc) require little to no thought, and complex joins between multiple tables become relatively simple to represent. I don't know of a single ORM that doesn't also allow you to execute raw SQL and get back objects, so in the case where you really _do_ need to do that, you can.

Yes, there exist counterexamples where you're doing very cutting-edge stuff with your DB that most ORMs can't handle. If you're doing that you aren't asking "should I use an ORM," you've already made that call and skipped this thread.

<comment><USER14> I don't understand how you think using an ORM == easier onboarding, because then they have to also know the ORM.

With straight SQL you just have to know SQL, which anyone messing with databases should learn anyway and is a way more portable skill than $ORM.

That said, I do agree if you are going to use an ORM, definitely use an industry-standard one for your language.

</comment></comment><comment><USER15> For those who don't use ORMs in large projects:

What's your preferred approach to store table definitions and migrations? Raw SQL queries there too? Doesn't it make them more susceptible to mistakes?

<comment><USER16> Since we use a lot of Java we use Flyway. It's got different ways to use it, one of them being straight command line- so you don't have to be a Java shop to use it.

I like Flyway over some others I've tried (like Liquibase) because it supports straight up, plain ol' SQL code for migrations and uses very simple file naming conventions to define versions and repeat operations.

The advantage we have being a Java shop is that we can also write our migrations in Java code, or mix and match. I've only ever done Java based migrations sparingly, all involved a big migration that involved sorting and sanity checking a lot of existing data.

For PHP/Laravel I've really liked Blueprint.

Although I like Flyway better than Liquibase, Liquibase can do a lot that Flyway can't and is certainly worth looking at.

I like the control of migrating my DDL by hand instead of the code first approach, and then having some ORM randomly changing data on boot.

We use Spring Boot w/ Hibernate and JPA a fair bit. We always turn off the code that would have the code manipulate our DDL, and we do write a lot of queries by hand, but we still get a lot of auto-magical stuff for free.

<comment><USER17> Having used both Liquibase and Flyway, I prefer Liquibase. For what it's worth, Liquibase does support raw sql migration too: [http://www.liquibase.org/documentation/index.html](http://www.liquibase.org/documentation/index.html)

<comment><USER18> Yes Liquibase is very flexible in how you can author changesets; it's certainly nice too that you can format it in XML, YAML, JSON, or SQL. All that said, what makes you say you prefer Liquibase to Flyway?

<comment><USER17> The main reason I prefer Liquibase over Flyway does not exist anymore, that was being able to downgrade my DB schema. It really is a new feature in Flyway and they were against it for a godly long time: [https://github.com/flyway/flyway/issues/109](https://github.com/flyway/flyway/issues/109)

And there is nothing in Flyway that Liquibase can't do and there is no reason to change back.

</comment></comment></comment></comment></comment><comment><USER19> I prefer a hybrid approach. I like to use an ORM for simple object manipulation and access. So for creating/updating basic models and simple object retrieval. When I say simple I mean queries like "where id =" and other very basic where statements. Anything more advanced I prefer to use raw SQL.

SQL is a language unto itself and it doesn't really need a layer of abstraction. I've found a lot of people use an ORM as a crutch instead of really learning the true power of SQL. I've spent too much time fighting against the ORM trying to get it to replicate what I want to do with SQL.

I find it much harder to maintain complex queries that are in an ORM. My personal workflow is to develop queries directly interfacing with the database and then more or less copy and paste the solution into code. If you use the query builder in the ORM you have to make the conversion from SQL to code, which I find to be pointless. SQL is very expressive, easy to read (once you learn it), and portable. Every ORM is unique and has its own syntax and style.

My one exception to where I prefer the ORM query builder over raw sql is when I'm building SQL that is heavily machine manipulated and has a lot of logic paths. Like for example a custom csv generator or an advanced query form. In those cases I find wrapping code logic around raw SQL to be quite messy and error prone. It flows much nicer when the builder can generate the SQL around your logic.

In either case people should learn SQL. Even when you use an ORM the end result is SQL. Understanding SQL makes it's easier to debug problems, improve performance, and answer the hard questions. I also think it just makes someone a more well rounded developer.

</comment><comment><USER20> I like using what is sometimes called Micro-ORM. Basically it does the mapping of query results to objects and sometimes has a basic query builder but you mostly use raw sql.

Dapper ([https://github.com/StackExchange/Dapper](https://github.com/StackExchange/Dapper)) is a great one for .NET.

<comment><USER21> JDBCTemplate would probably also qualify, it can be useful especially if you use Spring already. JDBI can be an alternative if you don't use Spring.

</comment></comment><comment><USER22> I use both raw SQL and Hibernate in my applications.

For simple CRUD (Create, Read, Update, Delete) operations Hibernate is excellent and does the job damn well!

But as your data model gets more complex, you need to write more complex queries. For example if you need to build a tree with child/parent nodes. This can only be done with CTE(Common Table Expressions) [https://www.postgresql.org/docs/10/static/queries- with.html](https://www.postgresql.org/docs/10/static/queries-with.html)

Hibernate and "all" other ORM's out there doesn't support CTE's and this is where you want to use raw SQL's instead. There are also other examples where I want to use specific function, for example the array_to_json function in PostgreSQL.

<comment><USER23> +1 ORM for simple CRUD and maybe the first version of getting lists (SELECTs). You will then quickly need raw SQL. I usually like to create "fake" ORM-like objects from raw SQL so that other code doesn't have to care too much where the data is coming from

</comment></comment><comment><USER24> I've only had bad experiences with ORMs. You get implicit behaviours and performance nightmares.

SQL isn't hard to write, unless the model is poorly conceived, in which case throwing an ORM at it will only makes things worse.

It really depends on how many tables you have, and how you generate their definition.

Personally I once had to start a fresh project with a large amount of tables, I generated the few CRUD requests I needed on all the tables, and commit them in my VCS. Then when iterating I would update and tweak them manually, either for performance tuning or new features / joins / schema changes etc...

This is not to say ORMs are to throw in the bin, I'm sure they solve some problems, but I've never fund myself in a situation where they would help me more than slow me down.

<comment><USER17> Yeah there is learning curve for ORM too. Never blindly use ORM without checking the queries it does to your DB. Enable the logs to see what it does, evaluate them, enhance the slow queries, if you don't know how, change those to raw sql.

I would never give up the development speed that using ORM gives me. And from experience there are at most half a dozen queries that I convert to raw sql in a huge project.

</comment></comment><comment><USER25> Depends the quality of the ORM really. For simple queries (basic insert, basic select), pretty much every ORM will do the job and in a more readable way than SQL. For something more complex, if the ORM isn't great, I prefer writing SQL directly.

</comment><comment><USER26> Clojure has several libraries (such as [https://github.com/jkk/honeysql](https://github.com/jkk/honeysql)) which basically let you build a representation of an SQL query as a Clojure data structure, and then programatically transform it. It is great when you need to do things like add joins and subselects programatically to a query based on selections from a UI, and is extensible enough to support many advanced SQL features.

</comment><comment><USER27> ORM, mapped to views for more complex stuff.

That said, mostly I use Clojure and there's no actual mapping to do. I use a library to create dynamic, composable SQL queries, but mostly have macros to generate crud statements. Everything gets returned in namespace qualified, idiomatic Clojure maps. It's all then covered by Clojure Spec so you know you're forming and passing everything around correctly if you need to.

</comment><comment><USER28> Personally, I prefer raw SQL, because I like SQL. It is one of the few languages where you can be _really_ clever without making maintenance a nightmare, IMHO.

OTOH, I tend to encapsulate the direct interaction with the database into a separate class/data type in my applications, that offers an interface to the rest of the code that is more in line with the application domain. So one could argue that I tend to write special-purpose ORMs over and over again. ;-) It has the advantage, though, that switching out the underlying DBMS is less of a pain, when it is required.

Full disclosure: All the projects I have worked on were fairly modest in size and complexity. The most "out there" thing I have done was to write and/or maintain a couple of SQL views and triggers to hook up our ERP system to other applications. Because our ERP system sucks. But on the plus side, I learnt a lot about SQL, which tends to feed back into my preference of raw SQL over ORMs. ;-)

</comment><comment><USER29> 1\. The Programming Language is factor in how well ORMs integrate into your app. If you're using a language which is expressive enough or has native support for querying, ORMs are an excellent fit. An example of a language in which ORMs work well is C#, on account of LINQ. But if you're on Java, it isn't as appealing. Hibernate still has value and is a very mature solution, but is nothing close to the expressiveness you get in LINQ.

2\. Performance is good enough, but with caveats. Some ORMs (especially newer ones) don't handle entity relationships very well, and sometimes do 1+N queries to fetch a single object. For eg, if you have a customer with an orders property, a naive ORM might SELECT the customer first, and issue separate SELECTs for loading each of the Orders. Entity Framework had this problem earlier, which they resolved later.

3\. Always watch the actual queries with a database tool.

4\. Be careful about Lazy Loading. Lazy loading defers the actual load until you use it. If the code always uses a property (that needs to be loaded from the DB), always eager load. eg: if you have 100 customers, and you usually need customer.creditCard, eager load "creditCard" (resulting in a join) to avoid 1+100 queries.

5\. You probably don't need an ORM with NoSQL.

6\. Inheritance relationships can be tricky, and have performance consequences. You can choose to have a (1) Table for the entire class hierarchy, or (2) a table for each Class. With (1), you get an ugly wide table with lots of fields and faster performance. With (2), if you were to select a list of Animals, and have Cat, Dog, Rabbit tables, you'll get cleaner tables - but poor performance because of joins. Add: generally avoid mapping inheritance via ORMs.

7\. Built-in caching, which you can find in some ORMs is probably not worth it.

8\. ORMs need not replace 100% of your queries. Some functionality will work better with SQL or even Stored Procedures - let it be.

9\. ORMs let you compose queries. I'll not go into details, but you could compose getCustomersByCountry() and getCustomersByAgeGroup() to get getCustomersByCountry_and_Age().

10\. Depending on the size of your project, see if patterns like Repository make sense (even if you're using ORMs).

11\. Last, the most important detail. It is not actually about saving lines of code - as much as it is about the ability to refactor. The biggest win from ORMs (in a statically typed language) is that if you edit a property, it changes the property across all files including your queries. Without an ORM, the code degrades quicker - because developers are reluctant to change.

<comment><USER30> Good answer. Also be careful with how you define OO object identity. Some ORMs cache in-memory objects (eg: lookup by id) and determine if an object is the same through equals() implementation and hashCode().

IMHO ORMs are nice if you use a OO heavy language, and want to reuse ORM classes in your domain and/or as DTOs. The biggest gotcha is that you will have to understand the quirks of the ORM (N+1, lazy, object equality, eager vs. lazy, types of inheritance, pk generation, integration with legacy DBs, polymorphism, etc).

Some legacy DBs make it very hard to integrate with an ORM (eg: no PK, Composite PKs with weird PK generation, etc).

</comment></comment><comment><USER31> Use the best tools available to you for the job at hand.

For instance, if you're using Python, there is SQL Alchemy, which gives you everything you will ever need in any situation, from ORM to parameter-bound raw sql, from a very feature-rich library.

Parameter-bound raw SQL is a fine option as long as you are comfortable with taking responsibility for testing and auditing for risks of sql injection. Don't use this approach unless you understand what the risks are and know how to manage them. Further, raw SQL is more challenging to debug in that you don't know problems until you vet issues at run-time. You're not entirely on your own with syntax checking, though-- there are sql syntax verification libraries that can help vet raw sql for you.

</comment><comment><USER32> (in between compiles...)

Raw SQL for simple stuff, of course - easier to debug, transportable to multiple languages.

For non-trivial stuff...

For read-write access, no choice but ORM imho - are you really gonna create stored procedures for every type of update?

For read-only access, raw SQL is an option, but it gets tricky with layers of VIEWs. Must be at least as powerful as Postgres e.g. partial and function indices to hide the underlying physical structure without paying some horrendous performance penalty.

(experience from trying to avoid ORMs in 3 startups... someday I'd love to add SELECT * MINUS <columns> to PostgreSQL to make VIEW authoring more scalable...)

</comment><comment><USER33> I use ORMs as a programmatic way to generate SQL for me.

I do NOT use ORMs as a replacement for knowing SQL or using SQL when it's appropriate. I think this is where a lot people get into trouble. They assume they can use the ORM and not need to know SQL.

</comment><comment><USER34> If you do use an ORM, you should still know SQL and know what raw queries it actually generates, and you should make sure it doesn't do anything cute like falling back to concatenating strings or some other unsafe practice for the sake of having a convenient API. Everyone assumes that using an ORM means better security than raw SQL, and maybe in the general case that's true, but the more abstract and complex a framework is, the more room there is for unknown and unwanted behavior.

The one thing you probably should _never_ do is use an ORM because you don't want to learn SQL or you just can't be bothered to care.

</comment><comment><USER35> As a Django developer, I wouldn't give up the Django ORM for the World. It's very expressive (albeit a bit verbose if you want to do non-trivial things — but you can do them), extensible, and all around a complete joy to work with.

It's the perfect balance of getting out of your way for trivial things, and letting you write your own SQL where it's required.

[https://docs.djangoproject.com/en/2.0/ref/models/querysets/](https://docs.djangoproject.com/en/2.0/ref/models/querysets/)

</comment><comment><USER36> Uh, neither? A good query builder library, though not one that tries to excuse you from knowing actual SQL. If you try writing SQL by hand, you _will_ eventually mess up and introduce SQL injection somewhere.

<comment><USER37> This - you really want the best of both worlds. Use an ORM that lets you mix raw sql in where needed, or generate it directly - sqlalchemy.org is a great example of being able to mix and match as needed using the same core library.

<comment><USER36> SQL Alchemy is pretty good at helping you build up complex and dynamic queries. I actually grew into mostly disliking Python, but other languages don't have SQL Alchemy.

There are some tools for that in other languages (Squirrel in Go, Arel - <USER2> thing backing Active Record), but I've found SQL Alchemy the most comfortable. Access to schema data is something that even I, mostly sceptical of "proper" ORMs, find really useful.

</comment></comment></comment><comment><USER38> The main advantage for ORM is security. The main disadvantage is that they often abstract away things that can impact performance heavely even if you are careful. I love Ecto (for Elixir) as a middle ground: closer to SQL, safe, still able to leverage your client models and well integrated into the language.

Examples: [https://elixirschool.com/en/lessons/specifics/ecto/#querying](https://elixirschool.com/en/lessons/specifics/ecto/#querying)

</comment><comment><USER39> I really like the concept of sqlx for Go. You write the SQL, but sqlx returns populates structs for you.

For really simple stuff, CRUD application, an ORM usually fine though.

</comment><comment><USER40> I got bitten by ORMs in my current toy project, [https://github.com/voltagex/YAMS](https://github.com/voltagex/YAMS). For the life of me, I couldn't get Dapper to join correctly. Now I'm running into trouble keeping the POCOs and SQL in sync. I may try to use some kind of code generation based on schema - I think there's a middle ground.

</comment><comment><USER41> For simple queries, I totally prefer ORM because the code that converts the results to objects is more work than learning/writing the ORM API.

For complicated queries involving joins and/or complicated conditions, in my experience writing the raw SQLs directly is simpler and more readable than ORM. However most ORMs let you use raw queries and you still get the benefit of not having to write the conversion code.

</comment><comment><USER42> There was a weirdly named thing called "mybatis" around awhile ago, that had a nice balance where the SQL was contained in one place and communication into and out of it was objects, but it was actual SQL (amenable to DBA optimization) and not some library doing things for you cleverly. Not sure if it's still a thing but I'm surprised that model isn't more common.

</comment><comment><USER43> Both

ORM for OLTP

SQL for OLAP

Expressed nearby to each other when there is shared business rules, for maintenance reasons:

        public static String PREDICATE_NO_GUMMY_BEARS = "user_preferred_candy <> 'gummy bears'";
        public static Predicate noGummyBears(Root<User> user, CriteriaBuilder cb) {
            return cb.notEqual(user.get("preferredCandy"), "gummy bears");
        }

</comment><comment><USER44> 1\. For static SQL, write views or procedures (i.e. raw SQL).

2\. For dynamic SQL, use jOOQ or something similar in your language.

3\. For the rare case of really _needing_ object graph persistence (loading a graph of entities, manipulating it, and storing the changes back to the database), or the less rare case of doing boring single-record CRUD, use an ORM. You don't want to do that with SQL.

</comment><comment><USER45> I'm firmly on the side of raw queries with binding params to avoid SQL injection. This is doubly true with complex queries. I can't count how many times I've crafted my SQL query very quickly, and then fought the ORM query builder.

Often, ORM proponents will say that is why any true Scotsman, erm, I mean ORM, will let you drop into raw mode. But that can have problems with testing. If you test against your ORM one way, it might just not work to test it against raw mode. And, thinking of testing, I'm also a fan of testing your SQL or ORM against a real DB (one that is set up and tore down per test). I know there are some unit testing purests that don't like that and thus prefer an ORM.

Many who like ORMs claim that they are so much faster for the programmer. Maybe for basic CRUD and composing simple conditional WHERE statements. And I contend that really is a "maybe." But I've been bit by poorly formed ORM queries (either does not do what you planned or is too slow, or one of my favorites: it returns ALL records and the ORM filters that app side to give you the ONE matching result) and I've lost enough time trying to force the ORM to make the query the way I want it, that I opt to skip that whole class of problem whenever I can.

<comment><USER46> Funny, calling people out on ' no true Scotsman' in your straw man reasoning.

<comment><USER45> Is it a straw man when you bring up regular arguments you've heard? I was under the impression that a straw man happened when you side stepped an opposing view by presenting a different argument. Since I wasn't side stepping an argument of the op's, is it still a straw man? If so, how does one present their opinions in comparison to others without automatically falling into a straw man situation?

</comment></comment></comment><comment><USER47> One thing I have found out useful is having a setup where you can easily write test cases for ORM queries using a real database and see a log file of generated SQL. Most of the "strange ORM errors" are much easier to figure out when you can see the DDL (like foreign keys) and the queries/updates that ORM is generating.

</comment><comment><USER48> ORMs are fun to play with, and are probably better for productivity in small apps.

However, for anything more significant than such, I find that writing SQL is not only more performant but also allows for greater productivity (do exactly what you want the way you want it without excessive digging around to see if it can been done/has been done).

</comment><comment><USER49> The biggest advantage of using RAW SQL is that you learn it 'quicker'. You will make mistakes, but hopefully those will be found before they make it to production. If you get used to ORMs, you probably won't know how to optimize your queries..

</comment><comment><USER50> Start with an ORM, for 99% of projects that is the good first choice.

Once you start growing and you can't solve your problems with the ORM or performance on the database starts to suck, start handcrafting where it hurts and gradually move to Raw SQL.

</comment><comment><USER49> RAW SQL of course. * Create the database for the queries you will use, then, for the admin panel, you can use an ORM (but why would you mix the 2?), but for front-end I always use RAW SQL (PDO, to be exact).

</comment><comment><USER51> For an MVP, use an ORM. Faster development.

For scaling to millions, start strategically using raw SQL for alot of things. You'll save alot of money on processing power and infrastructure costs.

</comment><comment> UK-AL MicroORMS are a good trade off, they do the tedious mapping between results and tables but you write the sql.

</comment><comment><USER52> if you mean embedding actual SELECTs in your code then no. Calling stores procedures is a much better more maintainable solution. Your app shouldn't have to know anything about the schema just from a separation of concerns view.

</comment><comment><USER53> People are so afraid of SQL they end up putting in 10x the effort trying to do it with an ORM. You just don't need it, just a day of studying SQL is an investment that will pay off 100-fold.

<comment><USER54> I'm not saying the solution is an ORM, but "fear" is not the only reason people avoid SQL: [https://news.ycombinator.com/item?id=1510177](https://news.ycombinator.com/item?id=1510177)

<comment><USER53> Not sure I understand your point about composition, why not use a CTE? [https://www.postgresql.org/docs/current/static/queries- with....](https://www.postgresql.org/docs/current/static/queries-with.html)

<comment><USER54> CTEs are such a limited composition tool. In our case, our ORM automatically applies user-configurable (ie, not hardcoded) complex access-control rules to each table depending on the roles of the current user. Doing this in the ORM is simple, because we can manipulate a query as a first-class entity. Doing it in SQL would be a massive pain.

<comment><USER53> Access control should be in the DB itself, or anyone can connect directly bypassing the ORM and have full access!

<comment><USER54> I'm not talking about access control to the DB, I'm talking about application users. Say you're writing a CRM, and you want a certain group of salespeople to not be able to view clients from Malta.

In our platform, the CRM manager can create a dynamic rule like:

      Role: group1
      Record Type: Clients
      Rule: Country != 'Malta'

Then our ORM will dynamically apply that to any query that accesses the Clients table when the logged-in user belongs to group1. For example, when the user searches for clients with a certain name, the SQL-equivalent query is:

      SELECT * FROM clients WHERE name LIKE '%John%';

But before sending it to the DB, the ORM see that the current user belongs to group1, and so will transform it into:

      SELECT * FROM clients WHERE name LIKE '%John%' AND country != 'Malta';

</comment></comment></comment></comment></comment></comment><comment><USER55> Most current ORM out in the market do not make things easier but instead otherwise. We need ORM to make it easy to build application that all agrees on OO principal meaning inheritance, one or more instant variable, polymorphism and etc.

My product have done all the above, at [http://shujutech.mywire.org/corporation?goto=ormj](http://shujutech.mywire.org/corporation?goto=ormj)

and me personally have felt the abstraction have been successfully achieved ever since because I never need to switch back to the ORM layer to build my applications. But, there're more to goes still............</comment>


Uber Tells Drivers to Shut Up with Quiet Mode - <AUTHOR> https://therideshareguy.com/uber-tells-drivers-to-shut-up-with-quiet-mode/ <comment><USER2> About time! The writer should quit writing and stick to driving people around.</comment>


The Nim Memory Model (2019) - <AUTHOR> http://zevv.nl/nim-memory/ <comment><USER2> This was an excellent read! I'm looking forward to the additional discussions (e.g. Nim's new runtime) described in the conclusions.</comment>


How to Find a Startup Idea - <AUTHOR> https://medium.com/@kunaljasty/how-to-find-a-startup-idea-c21c8fea844a <comment><USER2> For me, they are very unreliable and dangerous questions. Mostly asked by people who are wasting months to validate thoughts and seek the next imaginary unicorn, that doesn't exist yet and has no competition. :)

You immediately assume that you need to have more expertise and be 10x better than the competition. But the business building doesn't work like this, in most circumstances, you'll start from something small, and then become an expert in it. Placing research and business decisions in the hands of customers who mostly say "no, we don't need this..." is just unreliable. Sometimes most stupid and simple ideas can change everything, which was proven many times.

Don't waste time and focus on building actual products, then validate, pivot, validate, pivot, validate, stay, earn millions, acquire more companies, get more money, build some more companies, finish with an empire... But try to avoid Walter White's fate. ;)

<comment><AUTHOR> Definitely fair points.. what I was trying to get at is exactly your last point. The only way to know whether people want what you're building is to actually see if they're willing to pay for it. I think the biggest thing we are trying to avoid is building a product without knowing whether customers actually want it

<comment><USER2> My point was: Don't do customer research and build around your problems. You'll find clients in the same position willing to pay for it.

Pick your best promising idea, build it, start it, and see what's falling. Startups pivot multiple times before they settle, don't be scared of that.

<comment><AUTHOR> Understood. We've been emphasizing customer research to prevent time spent building the wrong thing. This talk explains more about the method we are following: [https://startupclass.samaltman.com/courses/lec16/](https://startupclass.samaltman.com/courses/lec16/)

</comment></comment></comment></comment><comment><USER3> Easy, see what google/ms is doing, and do the same.</comment>


Apple's App Store search is completely broken right now - <AUTHOR> http://techcrunch.com/2016/05/05/apples-app-store-search-is-completely-broken-right-now/ <comment><USER2> Has it ever worked? I shipped my app Combo three years ago, and App Store search still can't find it.</comment>


Google could make Chromebooks last years longer with a change to Chrome OS - <AUTHOR> https://www.androidpolice.com/2020/09/12/google-is-separating-chrome-from-chrome-os-its-a-big-deal-heres-what-you-need-to-know/ <comment><USER2> Google details a list of Chromebooks and their support end-date in a single list [0]. I randomly picked a couple with support ending this year and it seems like a decent chunk of the devices being EOLed in 2020 were released in ~2015. ~5 years of support for a <$300 laptop is pretty good IMO.

[0]: [https://support.google.com/chrome/a/answer/6220366#Acer&AOpe...](https://support.google.com/chrome/a/answer/6220366#Acer&AOpen&Asus&Bobicus&CTL&Dell&EduGear&Edxis&Google&Haier&HEXA&Hisense&HP&Lava&Lenovo&LG&M_and_A&Mustek&Medion&Multilaser&NEC&Nexian&NComputing&PCMerge&Poin2&Positivo&Promethean&Prowise&Samsung&Sector_5&Senkatel&SMART&Toshiba&Viewsonic&Viglen)

<comment><USER3> It's decent from an economic standpoint, but it's still environmentally wasteful, and among people buying a $300 laptop, there's probably a decent number who would have a difficult time paying to replace it. Also, the actual hardware of laptops hasn't changed that quickly in a long time, and when compared to Windows (which runs on basically anything), and macOS (which officially runs on 7-8 year old devices, and can be patched to run on older ones), the ChromeOS update policy looks kind of silly to me. I'm writing this comment on a non-Chromebook laptop that was purchased in 2015 and still works perfectly fine; it's crazy to me that I would no longer be able to use it because of an arbitrary limit on software updates.

<comment><USER4> I have a couple of Thinkpad T60 laptops, I think they were made in 2006 or 2007. Perhaps surprisingly, they are perfectly usable for many tasks. The obvious big exception is the "modern" web, but that can actually be a benefit when you want to put in some focused time and avoid distractions. Coincidentally, a lot of my best work in the recent past has been done on one of these antiques or one of my only-slightly-newer Thinkpads.

It's pretty amazing if you consider what it would be like using a 13 or 14 year old computer in 2006-7.

</comment></comment></comment><comment><USER5> Or Google could just provide long term software updates for their hardware like Apple does. Just because the browser portions continue to be updated sounds like the other portions won't be.

<comment><USER6> Can anyone with more Chromebook experience explain how much of the "OS" is going to continue to be updated with this new change? Chrome OS is very web- centric, so… does continuing to update the browser have a major impact to the life of these devices? Or is it literally just the browser?

<comment><USER7> Today they update everything until the end of life. Google has made no announcement about extending life with only browser updates - that would be great but I'd be surprised. They could just use this change to make faster updates by separating the browser and OS, that's the obvious thing.

It would be really great for google to extend support and make the browser updateable later - the browser must be the vast majority of attacks. I think they have to keep old hardware around and they want to use more power, it's hard to keep things working on weaker, older systems.

My guess is google doesn't add chrome-only updates to existing end-of-lifed units, it will only be for new ones. But I hope I'm wrong.

</comment></comment></comment><comment><USER8> Where does the 5 years figure come from?

I've always thought Chromebooks are supported 7-8 years.</comment>


Ask HN: What's Spotify NYC culture like? - <AUTHOR> I recently saw my dream opening, user researcher, posted for the NYC and Stockholm office. So I'm thinking of applying and just wanted to ask if anyone could describe more of the team/"missions"?<p>Any input and advice would be appreciated it particularly on the UX research team! <comment><USER2> NYC Spotify employee here. Spotify has a very honest, open, and autonomous culture. Spotify is comprised of many Missions which are defined by a business purpose like ads, user engagement, or analytics. Within a Mission you will have one or more Tribes. Each Tribe is loosely associated with the Mission goal and addresses a portion of the overall Mission. A Squad is a delivery team/product team. Squads are accountable for building great products. They are given autonomy to make the right decisions for the direction of their product. Squads function as "mini-startups", if you will. A grouping of many Squads is called a Tribe. A Mission will have one or more Tribes. It's a tad confusing and I'm sure I've gotten some of definitions wrong, but you get the general gist.

As for the people culture, Spotify values the growth of employees. We focus heavily on personal growth over product delivery. We believe if we build good people they will build good products. I was doubtful before joining Spotify that they would fulfill everything I was told (about the culture) during the interview process but everything has held true.

For better descriptions of Spotify check out the engineering culture video: [https://labs.spotify.com/2014/03/27/spotify-engineering- cult...](https://labs.spotify.com/2014/03/27/spotify-engineering-culture- part-1/)

I would encourage you to apply. Spotify is a great place to work.

<comment><AUTHOR> Thanks I really appreciate the perspective! Quick follow up, are you assigned a team from the get go and what's the the mobility between missions/tribes?

I'm definitely going to apply, but I image they get inundated with apps so I'm trying to learn as much I can for that cover letter (hopefully that counts for something,haha?).

Would you suggest I email a recruiter directly on top of applying online?

</comment></comment><comment><USER3> That seems like a very specific question, maybe something that you could get a faster answer to by messaging Spotify NYC employees on LinkedIn?

I worked at Spotify Stockholm (doing my master thesis there), and it was quite nice. Pretty much what you'd expect from bigger tech companies (Google, FB), only on a smaller scale. I'm sure you'll find a lot to do as a UX researcher since they are constantly experimenting with new features.

</comment><comment><USER4> Glassdoor is a great place to start your research [https://www.glassdoor.co.uk/spotify](https://www.glassdoor.co.uk/spotify)</comment>


Why Your Open Office Isn't Working (and How to Fix It) - <AUTHOR> http://blog.scribblepost.com/open-office-isnt-working-fix/?utm_content=buffera00d7&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer <comment><USER2> Sometimes the easiest way to "fix" the open office is to just switch companies.

If you're in a "thinking" business and your employer doesn't care if you can think, maybe thinking isn't that important to them, or at least not as important and something else.</comment>


Hddsurgery.com – interesting hd recovery tools and FIRMWARE - g-b-r https://hddsurgery.com <comment> g-b-r I ran into this by chance, I didn't even know there was a market for hard disk repair/recovery tools.

And they are from Belgrade! :0

The tools are not really affordable for a normal user, but still interesting I think.

Quite interesting is this too: [https://firmware.hddsurgery.com](https://firmware.hddsurgery.com) that is, a collection of firmwares for an enormous amount of HD models.</comment>


A new data leak hits Aadhaar, India's national ID database - <AUTHOR> http://www.zdnet.com/article/another-data-leak-hits-india-aadhaar-biometric-database/ <comment><AUTHOR> [https://twitter.com/zackwhittaker/status/977273903658696704](https://twitter.com/zackwhittaker/status/977273903658696704) Some comments</comment>


How In-App Purchases Have Destroyed the Game Industry - <AUTHOR> https://www.baekdal.com/opinion/how-inapp-purchases-has-destroyed-the-industry <comment><USER2> This covers mostly the pay-for-gems model of scamming, which is certainly a big part of the problem.

Another problem is that it is hard to find "complete" games now. Years ago, you could play a game for literally 200 hours and still not see everything. Now, for the same price, you get what feels like about 40% of a real game, and a series of ten-dollar "downloadable contents" fill in the rest of the game that you should have had.

</comment><comment><USER3> Yeah, mobile games are crap. If you want to play portable games get a Playstation Vita.

The console and PC games industry looks pretty healthy in term of creative output these days, both at the high end and the indie level. I am not worried, and the fact is there are enough Xbox 360 and PS 3 games you haven't played yet that you can be playing games for years.

<comment><USER4> They are only crap if you want free to play, still plenty of good premium games out there.</comment></comment>


How to tokenize Japanese in Python - <AUTHOR> https://www.dampfkraft.com/nlp/how-to-tokenize-japanese.html <comment><USER2> If you're interested in this you should take a look at Chrome's break engine source code for japanese/chinese: [https://github.com/unicode- org/icu/blob/778d0a6d1d46faa724ea...](https://github.com/unicode- org/icu/blob/778d0a6d1d46faa724ead19613bda84621794b72/icu4j/main/classes/core/src/com/ibm/icu/text/CjkBreakEngine.java) [https://chromium.googlesource.com/v8/v8/+/refs/heads/master/...](https://chromium.googlesource.com/v8/v8/+/refs/heads/master/src/objects/js- break-iterator.cc#75)

<comment><AUTHOR> So that works on similar principles to MeCab but it's more limited and performance is... not very good. I wrote about some of the issues with it recently here.

[https://github.com/polm/fugashi/issues/23](https://github.com/polm/fugashi/issues/23)

(Also, if you learned about Chrome's Japaense tokenization on HN, that was me too!)

</comment></comment><comment><USER3> For someone in the know, how different is tokenization strategy between Japanese and Chinese? The grammar/sentence structure is different and Chinese does not use kana or qualifiers for things like verbs in the same way but then both have compound words and lack of spaces in text.

Do languages like German which is rife with compound words have any overlap in tokenization or do you end up with completely different strategies?

<comment><USER4> My strategy for tokenising Chinese is brute-force: read 5 characters ahead, is that a word? No -> 4 characters, No -> 3 characters, No -> 2 characters -> Yes, copy to output, move 2 characters ahead, read the next 5, 4, 3, 2. It's very slow.

This is how humans do it though. [https://pingtype.github.io/docs/advanced.html#spacing](https://pingtype.github.io/docs/advanced.html#spacing)

If you have some Chinese text that you want to read, throw it into Pingtype (my program) and it should help you to pick up the vocabulary! [https://pingtype.github.io/](https://pingtype.github.io/)

<comment><USER5> >read 5 characters ahead

alright programmer question: why was the magic number 5? Are there no chinese words that are longer than 5 characters? Or does 5 characters cover 99.999% of all possible cases, and is therefore "good enough"?

<comment><USER4> It's the maximum limit for names on Ruten, a shopping site in Taiwan. That's also the reason I used the name 尸三十三尺 for deliveries for a while! ASCII characters weren't allowed.

There are some words that are longer (e.g. Mesopotamia) but in practice those are basically all proper nouns.

</comment></comment></comment></comment><comment><USER6> It seems a bit weird that the example somehow doesn't consider 'fugashi' a compound noun and claims it's 2 nouns, 'fu kashi'.

Maybe that's intended but then apparently this is pointless if you want to know how things are pronounced.

<comment><USER7> The key aspect not captured here is "rendaku" \-- the voicing of a normally unvoiced consonant in a compound word.

[https://en.wikipedia.org/wiki/Rendaku](https://en.wikipedia.org/wiki/Rendaku)

<comment><USER8> But rendaku rules are extremely complicated and often unpredictable , eg 中島 can be Nakashima or Nakajima depending in how the person chooses to pronounce it.

</comment></comment></comment><comment><USER9> There have been some recent attempts at creating EBNF grammar definitions for Japanese that try to balance simplicity and coverage [https://learn- japanese.org/2020/01/04/japanese-grammar-in-eb...](https://learn- japanese.org/2020/01/04/japanese-grammar-in-ebnf-notation/)

<comment><USER10> If I'm not mistaken, that's a post by yourself, so you could just say "I recently attempted..."

</comment></comment><comment><USER11> The moment I saw the title I thought of you Paul (polm). No doubt you are the world's expert on tokenizing Japanese.

</comment><comment><USER9> Also cool: [https://www.aclweb.org/anthology/Y03-1034.pdf](https://www.aclweb.org/anthology/Y03-1034.pdf) (parser from 2003 with 97% coverage on native text)

</comment><comment><USER12> Be careful what you do with a Japanese tokenizer. Just because you got an ability(or I'd like to call it probability since it's not perfect) to tokenize Japanese doesn't mean you can process Japanese like the language you familiar with. Please, don't do clever things. It's better to just leave Japanese string as binary blob and treat it as is, passing left to right without any modification.

It is my observation that the programmer of native Indo-European languages tend to have a delusion that their native language is so fundamental that any language processing they deemed necessary must be applied to the any and all languages in the world.

Which cause the locale library in most programming languages tend to have a feature that's unfit for Japanese and it break the Japanese. Yes, the presence of the locale library break the Japanese language support.

These locale libraries modify the string binary and break the Japanese encoding. You can't easily implement no-op local for Japanese because these modification are often cause by the fundamental common part of the library rather than language specific part.

People have a good intention. They want to support multiple languages. but it's a delusion that passing the string binary to locale library magically solve the problem. The locale libraries were often written badly for Japanese so it break the Japanese. I would like to call it locale-tainted.

Since The locale library is part of the standard library of the programming languages and many software relies on it. We can't just avoid using locale library without massive refactoring of the source code which is impossible given the available resource for localization. So if we, the unfortunate Japanese programmer, got a job of localizing locale-tainted existing software to Japanese, we have to come up some workarounds.

Modifying the source code to remove the locale library usage is the best but often not possible. Hooking locale library to replace it with Japanese-safe version are dirty workaround but it requires to reimplement most of the text manipulation which cost many man-monthes and rigorous testing, Imagine implementing a printf/regex library to replace the standard library that satisfy all the use case in the wild. The worst workaround is let the stupid locale library do whatever the stupid Japanese breaking string binary transformation they damn want, then, reverse-transform after the string binary passing through the locale library to fix the mess. A mess that was unnecessary in the first place.

I was involved in C++ Standard Committee but people out there are so delusional they think it's a good idea for a new standard library to depend on broken locale library because it help the localization. Those delusional people are also designing Unicode library now. They won't fart out a good library under such delusion. I lost all hope for this industry.

So please. Don't introduce stupid unnecessary language processing to the language you don't understand. Make our job less horrible.

<comment><USER10> Tokenizing strings is usually not something that happens unnecessarily, but it's required for the implementation of e.g. keyword search. So it's not something people can just avoid doing.

> These locale libraries modify the string binary and break the Japanese > encoding. You can't easily implement no-op local for Japanese because these > modification are often cause by the fundamental common part of the library > rather than language specific part.

Can you give an example of a situation where that happens? Is it an issue with e.g Shift-JIS encoding vs. Unicode?</comment></comment>


Ask HN: Suggestions for a user-friendly Privacy Policy - <AUTHOR>

Hello ,
I`m CEO of Guchex, and we are building a social blogging platform that will help Programmers, Scientists, Researchers and Geeks to exchange knowledge.
There have been several discussions about Privacy Policies against social platforms, and we would like your suggestions to build a privacy policy that will secure the privacy from our users.
CEO Guchex.com, Vinicius Melo <comment><USER2> some interesting ideas:

Privacy Nutrition Labels: <http://cups.cs.cmu.edu/privacyLabel/>

Privacy Icons: Knowprivacy.org, <https://wiki.mozilla.org/Privacy_Icons>

User Research and design suggestions around privacy (and privacy policies specifically): [http://createwithcontext.com/insights-digital-trust-and- priv...](http://createwithcontext.com/insights-digital-trust-and-privacy.php)

Disclosure: Im working towards some of these ideas on an Open source and CC licensed project with others at privacypatterns.org

There are references in my presentation available at <http://pii.privacypatterns.org></comment>


Don't be a git, use subversion - <AUTHOR> http://mkaz.com/web-dev/dont-be-a-git-use-subversion

<comment><USER2> Umm... _fuck no_.

There is no reason that you can't use git as a master repository system-- that's how most people treat GitHub anyway.

OTOH if you want to do anything besides the basic commit or update with Subversion, it's ridiculously difficult. Subversion is a SCM tool where people actually prefer to merge manually rather than deal with its conflict handler.

<comment><AUTHOR> I agree most people do use Git as a master repository system, so why deal with the extra complexity and just use Subversion.

It will save you a command on every commit, no need to commit and then push.

<comment><USER3> Because git is significantly faster, better at merging, allows cheap private branching and private changes (don't have to do everything in public just to have version control), allows staging of changes, allows offline work, allows "out of band" collaboration between developers, is up to 30x smaller repos (mozilla), more redundant (everyone has full history)... (more)

</comment></comment></comment><comment><USER4> "Don't be a git, use subversion" - no one ever

</comment><comment><USER5> If you must keep with subversion, explicitly authorize the use of git-svn for developers who are using git.

Git use causes smaller incremental commits, which can be squashed into bigger ones for re-merging, but makes for better, more ambitious changes, and easier rollbacks to working code. You get 85% of the benefit by allowing those who can handle it to use git as a subversion client.

</comment><comment><USER6> No need for an inflammatory (link-bait) title IMHO.

<comment><USER3> Self-posted linkbait, he needs the hits man! Just one more hit!

<comment><AUTHOR> The comments are really what juices me

</comment></comment></comment><comment><USER7> I think what the author is trying to say is that by saving a command for 'every action' that you take on git, you can offset the hours and hours of conflicts and manual work you get every time you try to merge a branch into trunk on SVN. Or maybe not.

</comment><comment><USER8> DVCS is so so much better than CVCS that developers generally love it hence the popularity it is seeing. You are trying to hold back the tide here :)

<comment><AUTHOR> There are complexities with DVCS that people gloss over focusing only on the positive. My view is that the complexity is rarely worth it for most company settings.

This article explains the complexity well: [http://steveko.wordpress.com/2012/02/24/10-things-i-hate- abo...](http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/)

<comment><USER5> That article is a huge strawman. His example is easily 3x more complex than it needs to be.

</comment></comment></comment><comment><USER9> Don't be a tool, learn to use your tools.

</comment><comment><USER10> Well, git sucks a lot, but switch to CVCS instead? No way.

<comment><AUTHOR> I never said git sucks, its actually quite powerful; but with the power comes added complexity that for most is not worth it

<comment><USER11> There are more and more devs who have only worked with git. For them, they will find svn complex. They'll be used to using branches and svn will get in their way.

Git is complex for _you_. The mistake you're making is in not realising that's not universally true.

<comment><AUTHOR> A very good point, and something I've considered. You might just be right and I'm just getting old and crotchety :)

I still see git requiring more commands for simple tasks and the model of what is happening has more moving parts (more complex). This gives git the ability to do a lot more, but my thought is for the majority you don't need the more.

</comment></comment></comment></comment><comment><USER12> AAH.... HAHAHHAHAHAHAHAHAHA

</comment><comment><USER13> I am curious to hear stats from your experiment in creating a fake HN controversy. Please report back.

<comment><AUTHOR> I don't think I created any controversy. The real controversy is whether you should use rebase or not.

My thought was just simplify and subversion might be the right tool for many jobs.

Everyone thinks I'm a fool.

As far as stats, if you really are curious. I received about 1,600 views on the article. Oddly no referrer data from HN, around 300 from Twitter, 150 from Google Reader and 100 from hckrnews.com.</comment></comment>


Preload Hints for Web Fonts - <AUTHOR> http://www.bramstein.com/writing/preload-hints-for-web-fonts.html

<comment><USER2> Can't you preload fonts by base64 encoding them and embedding them in CSS?

Ref: [http://sosweetcreative.com/2613/font-face-and-base64-data- ur...](http://sosweetcreative.com/2613/font-face-and-base64-data-uri)

<comment><AUTHOR> You can, but then you're limited to a single font format and you would not gain any benefits from the browsers' ability to download in parallel.

A lot of this will improve when HTTP/2 becomes more common (you can push resource to the browser and parallel downloads will become more efficient).

<comment><USER3> I use this technique to great effect, and i would recommend this. Woff i very well supported generally, and then i put a backup to the actual file for the lagging browsers.

[http://caniuse.com/#search=woff](http://caniuse.com/#search=woff)

</comment></comment></comment><comment><USER4> Since no browsers support these preload hints, does anyone know of any good hacks to force browsers to preload fonts earlier than usual?

<comment><AUTHOR> There are several hacks. Almost all of them rely on using JavaScript to make a XMLHttpRequest to retrieve font data. This will force the browser to load the fonts earlier by working around the normal @font-face loading mechanism.

Because you already have the font data in JavaScript you can then also store the fonts in localStorage. This way you can avoid making a request for them on the next page load.

Smashing Magazine wrote a bit more about this technique: [http://www.smashingmagazine.com/2014/09/improving- smashing-m...](http://www.smashingmagazine.com/2014/09/improving-smashing- magazine-performance-case-study/#webfonts)

I'm generally against this idea because you're basically reimplementing the browsers' caching mechanism. The CSS Font Loading API ([http://www.w3.org/TR/css-font-loading/](http://www.w3.org/TR/css-font- loading/)) will let you do this in a much nicer way and it already has pretty decent browser support (Chrome, Opera and Firefox beta).

</comment></comment><comment><USER5> Is this something you could configure server-side using SPDY? Start pushing font info when the page starts loading?

<comment><USER6> Yes, once HTTP/2 kicks in (what most SPDY actually is now, and what it evolved into) the server can push assets. That makes this feature obsolete.

Source: [https://http2.github.io/http2-spec/#PushResources](https://http2.github.io/http2-spec/#PushResources)</comment></comment>


Vodka delivers shot of creativity - <AUTHOR> http://www.sciencenews.org/view/generic/id/338406/title/Vodka_delivers_shot_of_creativity

<comment><USER2> Yet more evidence of the ballmer peak [1]. This is a very interesting study since it's saying what a lot of people knew "intuitively" about getting a little tipsy.

[1] <https://www.xkcd.com/323/></comment>


The decline of Stack Overflow - <AUTHOR> https://hackernoon.com/the-decline-of-stack-overflow-7cb69faa575d <comment><USER2> IMO, it's more elitists than trolls. I use SO more like a complement to Google rather than a Q/A platform because it's hard to break into the community as a low-karma newbie. It's very discouraging when you ask for help nicely, provide context to your question, and try to contribute back only to see your question immediately closed or the only replies you get are unhelpful or self-serving. Why even bother to put in the effort of asking a question when you are seen as the pool boy at a country club to everyone else.

</comment><comment><USER3> This is exactly why I hate SO.</comment>


Solve one of the worlds major health issues: $4000 - <AUTHOR> https://www.odesk.com/o/jobs/job/Visual-Recognition-Software-for-Shooting-Mosquitos-with-laser-Prototypes_~01b47830ea4bc8ceaa/

<comment><USER2> Sounds like they want the software AND the hardware developed for that figure. No problem :)

<comment><USER3> And then they slightly change the software to actually track <insert random military item here> instead of mosquitos and they would have a perfect defence weapon.

<comment><USER4> Sadly that is the problem with a lot of R&D in this kind of area.

Imagine a search & rescue robot able to navigate in hazardous environment, being able to identify a human being, opening doors, to reach them, to deliver medicine, or a transport-possibility.

And now imagine an mountainous area in Afghanistan and the robot not delivering first-aid...

The R&D is the same. That's why DARPA is funding exactly these kind of challenges. Or am I wrong here.</comment></comment></comment>


How Echo Nest API was used to create algorithmic remixes - <AUTHOR> http://lindsay.at/work/remix/dissociated.html

<comment><AUTHOR> This is something I do manually at performances.. With audible errors :-S</comment>


Neuroethics - <AUTHOR> https://plato.stanford.edu/entries/neuroethics/ <comment><USER2> Transhumanism can be viewed as a fusion of what already is given. It is a mere combination of two systems, artificial and natural, that might as well have evolved similar to a symbiontic relationship. Before the actual enchancement, we will have a phase of mingling technology like we do naturally today, extending knowledge beyond our own entity, sharing information and boosting awareness of critcal tasks through the world wide web. Then there will be enchancement. If there is manipulation through it, ethical or not, the world needs to be influenced before we reach critical mass as a species and by our byproducts. Else there won't be no need to ask such questions much longer anyway.</comment>


Show HN: Wrapulous – A simple link shortening and click tracking API - <AUTHOR> http://wrapulous.com/

<comment><USER2> Just one more comment:

Have you read this: [http://highscalability.com/blog/2014/7/14/bitly-lessons- lear...](http://highscalability.com/blog/2014/7/14/bitly-lessons-learned- building-a-distributed-system-that-han.html) ?

<comment><AUTHOR> No, but I will. Thanks!

</comment></comment><comment><USER2> I like the basic auth in the URL. I've always thought that websites should use less sign up forms and more quick easy solutions like this.

<comment><AUTHOR> Thanks! Yeah, I definitely wanted to lower the barrier as much as possible.

</comment></comment><comment><USER2> Nice thing, but why is this better than bit.ly and similar services?

Will it handle hundreds of clicks per second?

<comment><AUTHOR> I think bit.ly is certainly a more robust API. My goal here was to create something extremely easy to use and also learn a bit in the process.</comment></comment>


Ruby-Lang.org Redesign - <AUTHOR> https://www.ruby-lang.org/en/

<comment><USER2> I am surprised they finally did not choose the dark themed design that was posted here. Maybe I had the wrong impresion that it was the most liked so far, or that the all the other designs were going this wsy. Instead the winner is more of a serious "keep thing tidy" one..</comment>


Russians penetrated U.S. voter systems, says top U.S. official - <AUTHOR> https://www.nbcnews.com/politics/elections/russians-penetrated-u-s-voter-systems-says-top-u-s-n845721 <comment><USER2> It'd be nice to know which states were attempted, which states were successful. Just because it's "cyber" doesn't make it worth of keeping it a secret. If it were a physical attack, we'd obviously know about it.</comment>


Show HN: A simple coroutine library for Go - <AUTHOR> https://github.com/Freezerburn/go-coroutine <comment><AUTHOR> I was reading about coroutines recently, and figured I would make something simple to emulate the idea of coroutines in Golang. This basically just wraps some standard library functionality around goroutines and channels to give some tools to work in a coroutine-esque way.</comment>


Rodney Brooks, Andrew McAfee on AI and the Future of Work - <AUTHOR> https://youtube.com/watch?v=SEvYNQxzeNc <comment><USER2> Rodney Brooks is underestimating AI. He never has done any proper work in ML/AI

</comment><comment><USER3> Rodney Brooks is one of the best. He was head of MIT CSAIL and started IRobot. Let's see how he does with his new company...</comment>


Ask HN: Tips for the first employee joining a tech startup - <AUTHOR>

Hi,  I would be the first employee joining a funded,tech startup in US , providing a service which is  a web-based,consumer facing.
I don't have much experience under my belt-  and I would to make sure the ramp-up process goes with as few hitches as possible.
Any tips, any previous experiences of being the first few employees (as a developer) of a tech startup, would be really helpful.<p>Thanks  a lot in advance, for your  tips!!
 :-) <comment><USER2> You're going to be building things that many people will use for a long time in the future. Even that small script that converts a customer email to PDF, copies it to the shared folder, and prints it on the copy room printer could become a critical system. Find these small one-off projects and solve them before they slow down the business. I've made many small utilities that overtime got replaced by larger systems but without them, maybe the company wouldn't have grown large enough to afford the large system.

Think of yourself as a foundation-builder than a typical developer at an established company. Once you setup a git-flow or email distribution lists, you'll own these systems for a while and will be the expert on managing/fixing/growing them. Plan well but not too much. Get it out in production (inside the premises) immediately.

If you're working on external customer-facing stuff, start writing policies on how things should happen, if such policies don't already exist.

</comment><comment><USER3> Could you tell us at what stage the startup is? I.e. is there already code? One or more technical co-founders you're going to be working with?

</comment><comment><USER4> "Buckle up Dorothy, 'cause kansas is going bye bye"</comment>


Less than 7 Hours to go for Google Code Jam 2012 - <AUTHOR>

http://code.google.com/codejam/<p>What is your choice of programming language this time around? And how have you been practicing? <comment><USER2> It's only the registration which opens in a few hours, the qualification round is in a month: <https://code.google.com/codejam/schedule.html></comment>


TCP Traceroute - <AUTHOR> http://www.catonmat.net/blog/tcp-traceroute/ <comment><USER2> I'm not sure about `tcptraceroute` but `traceroute -T` seems to be using SYN packets with tweaked TTL value [1].

There is an even more interesting technique - injecting packets with modified TTL into a currently running and valid TCP/IP connection. This often can be used to detect network setup behind NAT on the server side. I think the most famous attempt was 0trace by Michal Zalewski [2] but there are many implementations. Oh boy, one day I even created an Nmap script to do this [3], those were the days :)

[1] <http://linux.die.net/man/8/traceroute>

[2] <http://seclists.org/fulldisclosure/2007/Jan/145>

[3] <http://seclists.org/nmap-dev/2007/q3/186>

<comment> X-Istence And that is why you should scrub all incoming packets and make sure that they don't have a TTL that is too low ...

PF's scrub reassemble tcp for example will make sure that the TTL can't be lowered in an already existing connection ...

[1] <http://www.openbsd.gr/faq/pf/scrub.html>

<comment><USER2> Alternatively - watch out what ICMP errors are outgoing from your servers. (But don't block all ICMP or you'll screw up MTU discovery [1])

If you're worried about exposing your internal setup you also need to filter packets with unusual IP flags such as "Record Route" [2] or "Internet Timestamp" [3]. Fortunately scrub should notice that.

[1] <http://en.wikipedia.org/wiki/Path_MTU_Discovery>

[2] <http://tools.ietf.org/html/rfc791#page-18>

[3] <http://tools.ietf.org/html/rfc791#page-22>

If you have a source NAT on your servers, it's likely that an attacker can easily detect that, no matter ICMP / TTL / IP options setting. Running p0f on established connections will show your setup, for example:

<http://seclists.org/nmap-dev/2007/q1/175>

<comment> X-Istence It becomes much harder to identify NAT when you also scrub out going packets, and change the packet IP identification field with a random-id.

Other things that help as well is to not load balance the TCP/IP connection, but rather terminate on the first machine, then pass the connection through using something like varnish/haproxy.

</comment></comment></comment></comment><comment><USER3> Hi. Author of the original tcptraceroute here.

I first wrote tcptraceroute is 2001, while I was working for a large Mid- Atlantic NSP. I'd routinely see customers (and our NOC staff) reporting that traceroutes to many popular sites (such as ebay.com, microsoft.com, etc) were broken, and wondering if their connectivity was somehow defective. I would have to explain (again) how traceroute worked, and how the probe packets it uses are now (sadly) routinely firewalled, thus breaking our diagnostic tools.

At one point, the idea struck me that there was no reason we couldn't use any type of packet as a probe packet for traceroute -- including packets that firewalls found permissible. After a night or two hacking with libnet and libpcap I had a working implementation. Suddenly being able to traceroute through those firewalls and see the internal network of those large networks felt magical, like having X-Ray vision. :-) Over time, I added other features that provided even greater visibility -- such as the ability to detect when some NAT/load-balancers aren't doing as good a job as they could be, and thus revealing the internal IP address you're being NAT'd to. (Have a peek at <http://michael.toren.net/code/tcptraceroute/examples.txt> for some example output.)

I haven't done a great job of investing time into tcptraceroute over the past few years. The code is still functional and hasn't suffered from any bitrot, but the last "beta" release was "1.5beta7", back in 2006. There's no reason it shouldn't have been released as "1.6", I just never got around to officially "releasing" it. There are also a bunch of additional features I've contemplated over the years that I'd really like to add. This thread has definitely invigorated me to put more energy into the project soon, which I'm grateful for. :-)

Tangentially, one of the annoying things about "traceroute" programs in general is that the name is very overloaded, with many unrelated projects over the years calling themselves "traceroute". Further complicating things, a brand new project called "traceroute" was started a few years ago with the stated goal of only supporting Linux, and wishing to be the one, true traceroute in all Linux distributions. That project also implemented the ability to use TCP probe packets, which is awesome. I'm glad to see that there are other implementations out there. But sadly, they're also distributing a shell script called "tcptraceroute" that invokes their traceroute program with the flag to set the probe type to TCP. In Debian, if you have the "traceroute" package installed but not the "tcptraceroute" package, typing "tcptraceroute" will invoke their traceroute program. If you instead have both the "traceroute" and "tcptraceroute" packages installed, typing "tcptraceroute" will invoke my traceroute program. As the two programs differ in other ways, this can be really annoying, and lead to the type of confusion that can be seen elsewhere in this thread. I've also received a number of messages from people asking for help with "tcptraceroute", only to have us both later figure out that they're really running the other "tcptraceroute" program, which is very frustrating for both of us.

I'm not sure what the best course of action is. I strongly believe in, and advocate, open source. I want other people to be able to look at my code, learn from it, borrow useful parts, and distribute changes. And yet, I really don't want someone distributing a program that has the same proper noun I chose years earlier for my own project. This is something I've thought about off and on over the years as I consider releasing (and naming) other open source projects, but don't yet have a good answer. I suppose one solution is to utilize trademark law, but that's something I have very mixed feelings about.

This turned into a much longer post than I intended :-), but if anyone has any thoughts, I'd love to hear them! My contact information can be found in my profile.

Thanks!

</comment><comment><USER4> I am not sure how new this functionality is. Based off the changelog tcptraceroute has been a shell wrapper since 2007.

        2007-07-19  Dmitry Butskoy  <firstname.lastname@example.com> - 2.0.6

            *  Add tcptraceroute(8) shell wrapper

        2007-07-16  Dmitry Butskoy  <email@example.com> - 2.0.5

            *  New implementation of tcp method ("-T"), using
               half-open technique. The old implementation module
               renamed to "tcpconn" ("-M tcpconn").

<comment><USER5> Ah sorry, I should have said relatively new functionality. Also I should have mentioned that there are different traceroute implementations. I'll update my post.

Edit: updated the post.

<comment><USER4> I think route9's firewalk did this back when I had dial up.

<comment><USER5> Yeah. Well, I actually wanted to write about tcptraceroute program originally, but then discovered that traceroute on one of my systems had the -T flag. So I thought, wow, traceroute now can use the tcp protocol. That's why I wrote "was added recently" because I hadn't seen the -T flag before. It turns out that that system had the <http://traceroute.sourceforge.net/>, while my other system had the ftp://ftp.ee.lbl.gov/traceroute-1.4a12.tar.gz, which doesn't have -T.

</comment></comment></comment></comment><comment><USER6> "Was added just recently" - not sure about being added to the traceroute program, but I've been using tcptraceroute for years.

It is very handy.

<comment><USER5> I updated the post. It wasn't really added just recently. Here's why I said that: <http://news.ycombinator.com/item?id=5276983>

</comment></comment><comment><USER7> Hasn't Windows tracert always used TCP?

<comment><USER8> No, the difference is that the Windows version defaults to ICMP, while the Linux one to UDP.</comment></comment>


More Readers Are Picking Up Electronic Books - <AUTHOR> http://www.nytimes.com/2008/12/24/technology/24kindle.html?hp <comment><USER2> Man, I love the whole evolution of the Ebook movement. Think of what it will be like to have access to any quantity of information at any time, in a format which allows you to process the information without the fatigue associated with standard monitors.

Presumably, Ebook readers will assume capabilities reminisce of today's laptops - i.e. the ability to download most books and store them indefinitely. This means we might be able to store entire libraries on these paperback-sized devices. Not that the progression of this technology isn't fairly obvious, but it's still nice to fathom what will be possible in the future, as far as distribution of information is concerned.

Who knows, maybe no more college textbooks? One can only hope.</comment>


Ask HN: Why are there no powerful free refactoring libraries for text editors? - <AUTHOR> Editors like Emacs, VI, etc. are great, but IDEs can do much for you if they know the language more intimately like IntelliJ knows Java.
But why are there no free alternatives for refactoring? Is there some difficult technical problem?
If we consider, for example, Java and refactoring then Rename Variable, Extract Method and similar features do not look very hard to implement. There are libraries for parsing Java and if we have the syntax tree then it's just a matter of performing the modifications on it.
Parsing broken code may be a challenge, but a powerful refactoring library would be very helpful even if it could work only on compilable code. Text editors could just call the library and reload the source files after the refactoring is done.
LSP is a step in the good direction by providing completion, jump to definition, etc.  Why are there no similar libraries for source code refactorings? What is the difficulty here? <comment><USER2> Using Emacs or VI for Java is something for masochists. Helping them with refactoring support would take away their fun/pain. Doesn't use the Java LSP the Eclipse IDE? Maybe it would just be easier to configure your IDE like emacs.

<comment><AUTHOR> Unlike VIM people don't use emacs for the keybindings, so you can't just configure the IDE to work like emacs, because IDEs do not have those features (e.g. creating quick throwaway functions for some current task which can be inserted into the editor live, without restarting, etc.)

If Emacs has access to a refactoring library and completions via LSP then it could have the strength of Emacs combined with the strong language support of IDEs. I'm saying this as a long time Emacs user who also used Android Studio a lot for Java programming, so I can appreciate the fortes of both sides of the fence.

</comment></comment><comment><USER3> You are mainly talking about compile time checking. But due to the weak types in Java, you'll end up with uncaught compile and runtime errors.

I'd look into a strong type system like Haskell, F#, shoot even Rust will help in large refactorings being easier

<comment><AUTHOR> I did not talk about compile time checking, but refactoring, making assisted transformations on the source code.

<comment><USER3> Ok at what point does this occur, pre runtime or during runtime ?

<comment><AUTHOR> When you edit the source code, so pre compilation, pre running. Refactoring is a tool to automate manual editing.</comment></comment></comment></comment>


TSA "Quiet Skies" surveillance program targets innocent U.S. citizens - <AUTHOR> https://boingboing.net/2018/07/30/tsa-quiet-skies-surveillan.html <comment><USER2> This is a dupe of the much more thorough Boston Globe article from two days ago:

[https://news.ycombinator.com/item?id=17635761](https://news.ycombinator.com/item?id=17635761)

I'm not a huge fan of all the borderline off-topic political articles, but if we're going to do it, it'd be nice to choose the original source that was referenced four times. As it stands, we're not even adding anything new to the conversation.

</comment><comment><USER3> I have not understood the purpose of anything about this that I have read. I have heard (NPR) that any data they collect does not roll up into other three letter agencies records. They also mentioned that it in no way could prevent someone from boarding a flight. All it could pretty much do would be to pull you out for "random" additional screening. It really seems like an example of a solution searching for a problem.

<comment><USER4> You might not be wrong. This could have been the brainchild of a contractor who is now profiting from the program.

They might also need "negative" training data to train some kind of machine learning models. Maybe they only have data on criminals, and want data more on non-criminals to help train their models.

Maybe they _are_ looking for something specific, but what they're looking for is classified.

Basically: who the hell knows?

</comment></comment><comment><USER5> I've been telling most of my tech friends, especially the ones in tracking/adtech jobs, to start paying what I call the "Orwell Tax".

You pick a number of anti-surveillance nonprofits (EFF, ACLU, RestoreTheForth, etc.), and sign up for a recurring donation of $19.84/month or $1,984/year (whichever your budget allows).

If you're working in a surveillance/tracking job and don't want to quit, the least you can do about the spread of the surveillance state is to pay the Orwell Tax.

</comment><comment><USER6> Some previous discussion:

[https://news.ycombinator.com/item?id=17635761](https://news.ycombinator.com/item?id=17635761)

</comment><comment><USER7> My guess would be that this is going to establish a 'baseline' for passengers to be fed into learning models as labeled data set. Unclear how much that would help since there really isn't a baseline of true positives (that I'm aware of).

</comment><comment><USER8> Not trying to be rude here, but this is basically what the U.S. does to _anyone_ else in the world by default... and they don't like it either (using anyone instead of everyone on purpose here)</comment>


I study liars. I've never seen one like Donald Trump - <AUTHOR> http://www.chicagotribune.com/news/opinion/commentary/ct-donald-trump-liar-20171208-story.html <comment><USER2> Comparing self selected data on lying to a malicious political count of lies, "misleading" statements, and flip flops?

The basis for this article is weak. It's a shit post masquerading as data science.</comment>


Show HN: TopOfTheCoins.com – the "MillionDollarHomepage" of the crypto-era - <AUTHOR> Hey,
For those that haven't heard of it before, in 2005 a website was launched called http://www.milliondollarhomepage.com/. The site took the internet by storm, became pretty iconic, and genuinely did raise > $1,000,000.
As part of my goal for 2018 to learn more about crypto, this Jan I launched a side project: https://www.topofthecoins.com/
You can post a message simply with an Ether transfer. The message that has the most Ether is the one that remains featured at the top of the site. It's amazing exposure for anyone posting a message, as we currently have thousands of tech and crypto enthusiasts visiting the site.
As of writing, the top message was posted for 0.00126ETH (<$2), which means if you post a message with any more than that, then your message will be featured at the top of the site (until someone else posts a message with more Ether)...
It's a bit of fun to learn about crypto stuff, but it's actually starting to take off, which is quite exciting. I don't expect it to match the success of Million Dollar Homepage, but I'll sure try...
Be good to hear everyone's thoughts.
Thanks, Joe <comment><USER2> oh sweet. they are multiplying

[https://thousandetherhomepage.com/](https://thousandetherhomepage.com/)

<comment><USER3> I guess that is why I did not buy Ether.

<comment><AUTHOR> Why is that?

<comment><USER3> Monetizing completely useless stuff on the back of a block chain.</comment></comment></comment></comment>


MagicJack's Next Act: Femtos, Softphones, And…an IPO? - <AUTHOR> http://www.nytimes.com/external/gigaom/2009/07/05/05gigaom-magicjacks-next-act-femtos-softphones-andan-ipo-53934.html

<comment><USER2> How are they able to make MagicJack so cheap? Don't you get a real phone number? Most other services, like SkypeIn, charge quite a bit for the ability to call in, much less out.

<comment><USER3> They're set up as a real telecom, so they can create numbers for free, instead of having to buy them from another company.

</comment></comment><comment><USER4> this emperor has at best, some scanty underwear on. the jack deal is to prepay for a service that is many time more inconvenient than its substitutes and saves a few cents. what that means for customer renewals and business sustainability should be pretty obvious even if it remains undisclosed.</comment>


Ethereum Casper PoS Update - <AUTHOR> https://www.reddit.com/r/ethereum/comments/6pmye8/incentives_in_casper_the_friendly_finality_gadget/ <comment><USER2> Interesting comment by jps_ :

> _In a "Hard Fork", shouldn't we expect a version of the "nothing at stake" > problem to play out? i.e. that validators have precisely zero to lose by > validating on both sides of the (now non-communicating) chains? Slasher > won't work across a fork._</comment>


How do you go about hiring a web designer?  How much would you expect to pay roughly?  What if the design fails to impress potential users? - <AUTHOR>

<comment><USER2> When I was looking for a designer, I called many firms. The end result - expect to pay 5k-10k for a small site (~10 pages). This was outside my budget....

So then I tried craigslist. I received a lot of interest, but found only one good candidate. But this candidate found another contract before I could get back to them. Craigslist is cool for simpler things like company logos, but didn't work for me on the web designer front.

So, I contacted a prof who taught a project course at a design school (university) in my area. I asked this professor to ask his best student to contact me. I looked over the student's portfolio and was really impressed. This design student turned out very good work for a very reasonable price.

<comment><USER3> www.mintpages.net is a private forum for designers. I've had luck asking for someone there.

<comment><USER4> Hehehe...It appears one must be a designer to join. Then why would we need a designer?

<comment><USER3> I applied saying that I was an entrepreneur and was interested in hiring a member. They let me in and immediately instated a rule that you needed 15 posts before you could post in the "Help Wanted" forum.

</comment></comment></comment></comment><comment><USER5> How do you go about hiring a web designer?

Past custom references, portfolio and most importantly designer's overall attitude.

How much would you expect to pay roughly?

Too vague to answer...really depends on WHAT exactly you've hired the designer to do. Is it to take a detailed concept YOU give him and convert it into a design(cheap)? Is it to THINK through your technical product, think how users will use it, then design(more work)?

What if the design fails to impress potential users?

I don't know any designer who will guarantee that your users will like the design so this one is tough.

-Zaid

</comment><comment><USER6> Here is a good blog post I read some time ago about how this company chose their designer:

<http://www.barenakedapp.com/the-team/how-we-picked-the-designer>

Figuring out the best designer for your site is, generally, more art than science. Just like choosing a developer. One thing you can do to reduce your risk is to hire someone for a small task first (say, do the logo), and if you like their work, ask them to do the whole project.

</comment><comment><USER7> Hire a designer who has more than a few years experience and it able to deliver not only the Photoshop files but the front-end (standards-compliant code!) to you as well. This means this person is able to code by hand and will understand the implications of his/her design choices when it comes to developing the actual website. Also, you get kind of a "two fer" this way as you don't need to hire a second person to do the front-end code. Another advantage is the capable designer can better communicate with the back-end team.

Pay this person well as you get what you pay for. Web design like many other disciplines in the web field, is a highly lucrative job with new opportunities coming along everyday. It's important for the survival of your own company to make sure you make the hotshot you hired feel satisfied with the salary and your company.

However, if you are just looking for a junior person on the cheap, you can find that but then you get junior, cheap results. It's better to bring in junior people to work under your senior person and build him/her into a senior from there.

</comment><comment><USER8> An un-holy amount will charge out the ass. Many have few clients, so their business model depends on charging each client alot, almost scamming them.

Web design is not rocket science. With all the tools and stuff available to designers today, there is no reason the "clothes" of a site should ever go over a few ,000'.

Don't pay 20-30k. Leave that for big/unsophisticated companies.

p.s. A lot of designers do suck. With developers, many can get the task done "eventually", but with designers, many can't get what you want... ever.

<comment><USER9> Web coding is not rocket science, but good web design is like good engineering. Good tools will help, but knowing what to do will help a lot more, and that's what you pay the web designer for. Saying "with all the tools and stuff available to designers today, there is no reason a site should cost more than a few thousand" is like saying "with all the IDEs and stuff available to coders today, there is no reason a program should cost more than a few thousand." Programmers know that that's BS; web designers feel the same way.

Unfortunately, it's a lot like hiring a programmer in other ways -- the best designers will easily be ten times as good as the worst ones, and there's no necessary correlation between skill and rate.

So returning to the original question: look at the web designer's portfolio. Ask questions about web standards and (X)HTML compliance, usability, A/B testing, cross-platform CSS issues, readability, copywriting, audience. A good designer will understand these things and be able to explain them to you in terms you'll understand. Make sure you turn on your BS detector too, though, as a bad designer will try to baffle you with buzzwords.

And one of my favorite interview questions, when looking at a designer's portfolio, is "Why doesn't Site X validate?" The point is not to get the right answer, because there isn't one, but to figure out how the designer approaches these tradeoffs. I've also never interviewed a web designer who provided a portfolio of only valid HTML and CSS.

<comment><USER9> Oh, and how much you'll pay is highly variable. It depends on the job market where you are, and how saturated it is with competent web designers. A ballpark of $5K-$10K is not ridiculous, though, depending on the amount of work.

And what if it fails to impress potential users? Then your web designer wasn't very competent, because that's exactly the sort of thing he's supposed to understand about your audience. A good web designer will bounce ideas off of focus groups and do usability testing, and then when the site goes live will conduct A/B tests.

Finally, the best way to make sure that the site doesn't impress potential users is to micromanage the web designer. You need to ask him or her about the web analytics numbers, but if you insist on wordsmithing on every page and monkeying about with fonts and layout yourself, you might as well just do the site yourself. (This is something I've seen repeatedly: the web site winds up being designed for and by senior management against the advice of the web designer, the potential users stay away in droves, and the web designer is blamed.)

</comment></comment></comment><comment><USER3> I like this designer and he's very friendly. <http://www.eoghanmccabe.com/>

<comment><USER4> I'm sure he's an absolute gent. But his webpage is nearly unreadable in my browser. Fonts step all over each other (I'm guessing he's forced line height to be smaller than the font).

First requirement for web designers I hire: I need to be able to read the damned page.</comment></comment>


Should application users be database users? - <AUTHOR> https://stackoverflow.com/questions/341271/should-application-users-be-database-users <comment><USER2> Is this even a question? I cannot believe the accepted answer says this practice is okay. Please, never do this.</comment>


Show HN: Email based service to help practice drawing and free reference images - <AUTHOR> http://sketchage.com <comment><AUTHOR> Emails go out every day at 2:00. Here's todays issue [http://us15.campaign- archive1.com/?u=c6f4641a67aaac83a748e0f...](http://us15.campaign- archive1.com/?u=c6f4641a67aaac83a748e0f31&id=b3b6d7ecb3)

If you wanted to try it out, sign up your email.</comment>


The Pursuit of Artificial Intelligence Part 1 (2 and 3 also available) - <AUTHOR> http://www.thepursuitofquality.com/post/1/the-pursuit-of-artificial-intelligence-part-1.html

<comment><AUTHOR> Ran across this blog today, thought people may enjoy the content (some of the other posts are pretty interesting too).

Came across it from being intrigued by a commenter's logo on this post: <http://blog.asmartbear.com/how-to-say-yes.html> (gavin miller's comment). Just goes to show how catchy logos can bring in page views. lol</comment>


Street View: We can trike wherever you like - <AUTHOR> http://googleblog.blogspot.com/2009/10/street-view-we-can-trike-wherever-you.html <comment><USER2> I want to see them attempt Venice; although technically 'street' view would not be accurate. It would not be easy, between canals, pathways, and especially all the bridges: foot traffic only, with stairs, and you'd have to keep the camera steady somehow.

The results, though, would be very cool.

<comment><USER3> I don't think holding the camera steady it that big a deal. In the video, he's biking a non-paved hill-path, and the outcome is fine. A bit of shock- absorption and a fast shutter is all that's needed.

<comment><USER4> I expect this is part of the reason they only have pictures from bright and sunny days in most places.

</comment></comment></comment><comment><USER5> I wish Google would make a web interface that pre-cached the street view frames and implemented a better mouselook and keyboard controls so you could 'drive' the streets. It would be a great way to explore and learn the layout of new areas.

<comment><USER6> I suspect the problem Google has with a lot of things is scale. To take this for example it might not seem like a big deal to pre-cache images but when you look at the millions of people who probably use Google maps and assume that a lot of that cache will be wasted (people closing the site, people only going 1 of possible 3 ways at an intersection, etc...)

So even though each individual is only caching a few wasted images per visit the end result is probably terrabytes of wasted bandwidth for something that's a fairly minor feature (I agree it would be nice but it's not a "must have")

<comment><USER5> Oh, I agree, but it _would_ be cool :)

</comment></comment></comment><comment><USER7> Oh - I saw what I guess was a prototype of this about a year ago on Memorial Drive in Cambridge, MA. The rider was stopped and fiddling with something. Didn't look as slick as the one in the pic, but it did have some big Google stickers on it.

I should have taken pics of it, because people I told about it didn't really believe me.

</comment><comment><USER8> I have a project that is doing the same thing, long before Google invested in a Trike:

<http://openviewproject.org/>

Our goal is to make this kind of tech available to anyone who wants to put it together, with a solid software infrastructure to do interactive panoramas.

If you're interested in helping and have Python / Django experience, please contact me!

</comment><comment><USER9> Wherever we like. . . Really?

How about a shanty town? Or a drug compound deep in the Colombian jungle? Or just a plain ordinary war zone? Come on Google. Where's your balls?

</comment><comment><USER10> I wonder when they will start mapping the inside of public buildings.

<comment><USER11> I wonder when they'll start combining street view with infrared depth sensing to create high detail street level 3d projections...

<comment><USER12> They seem to be more keen on crowdsourcing the 3D part, with that new Sketchup plugin.</comment></comment></comment>