Inside a fundraising in France: a CEO point of view - <AUTHOR> https://medium.com/@flavienguillocheau/blitzkrieg-fundraising-7836e7d6c40c <comment><USER2> Congratulations, raising money in France is harsh. This is in part due to the fact that start-ups in France have a much harder time getting off the ground than in the rest of Europe because of various government regulations, and in part because the 'home market' does not make for an easy jump abroad. The latter also somewhat affects German start-ups but they have Austria and Switzerland as relatively low hanging fruit after the home market.

Out of all the deals I've looked at (and I consider Europe my working territory) only a very tiny minority were in France.

One sentence from the article jumped out at me:

> When you want to control all the information that filters out of the company > during such an intense and important moment as a fundraising that's > definitely not a good idea: never let your team alone with investors.

I've yet to see any company where the CEO wasn't comfortable with having the team talk with investors unsupervised, and trying to control the message to this extent might look like you have something to hide which could cause investors to drop you. Keep in mind that as the party that is emitting shares you have a fiduciary duty to disclose and anything that you hold back (or that you tell your employees to hold back) but that you do know about can come to bite you later on.

Another note: disclosing what went on between yourself and VCs that invested in your company or gave you terms sheets is pretty bad form and I would advise against it. Any communications you've had in the process of your fundraising are between you and the VCs and should not be disclosed, even in blog posts about fundraising.

<comment><USER3> Hi! Thanks for your feedback, we didn't had anything to hide hopefully, it's just during this momentum, I've became slightly paranoid about loosing it and you never know how it can change, not sur it's the good way, that's just how I thought about it :)

For publishing this post, I discussed with our investors, and my idea was simply to share something I found so few testimony about. And if it can help other entrepreneurs or even investors understand what happens in CEOs head I think it's worth! Our investors are nice and comprehensive <3

</comment></comment><comment><USER4> On a side note looking at the job offers on the company site i can't understand why people that want to build a solid company would offer such a low salary. They offer 40k-55k for a senior engineer, 40k is like 2600 euros a month.

I think the french tech sector is shooting itself on the foot by not adapting salaries faster to the job market. Even floor managers in retail stores make more money in Paris. They will lose a lot of talented people to other countries like this. Plus salaries are rising anyways so yo hire some people at those salaries and then when you want to hire more people you need to pay the new ones a lot more so that generates tensions inside the teams because new hires are better payed.

And its a cycle, because software engineers in France are considered not worthy of big salaries, so they pay peanuts. Talented engineers just move to other countries and whats worse the number of new graduate engineers stagnates compared to the demand because people don't regard this profession as something desirable. in 5 to 10 years when demand for labor increases France wont be prepared.

Very short sighted thinking from ceos in france.

<comment><USER3> Hi! Interesting thought here, But people we have in recrutement process ask those kind of salary we didn't made those up. And probably the salary in France are undervalued, probably talents will seek US salaries, but I don't feel that we are losing talents when I see the peiole we've hired, but I don't have the answer here and you might be right. On the salary range it's often wide because we are not looking specifically for senior persons: yes 40k for a senior dev doesn't make sense. Though The last idea doesn't make sense, salaries evolve during the life of a startup and they mostly increase so this scenario wont happen and probably short sighted thinking from you to think salaries are managed in such a simplistic way ;)

<comment><USER4> Yes i know its not just you i was thinking more of the dilemmas of the developing software sector in Paris, congratulations by the way. What i see is that engineers are seriously underpaid in Paris at least. This is also the fault of french engineers, i think a lot of them think of money as dirty and are afraid to negotiate what their work is worth. And eventually that will generate a serious shortage of talented workforce for french companies. That situation could lead to the french tech sector not being able to be competitive with some other European countries like Germany.

[edit] I'm not even talking about silicon valley salaries. I compare the salaries to what skilled workforce in France earns which is minimum 4000 after tax per month, that is the lowest salary for highly prepared professionals where there is a lot of demand for workers. You have a lot of software devs working for half of that in France. For me when the reality of the workforce shortage hits the companies its going to be too late.

<comment><USER3> And we are only talking about French salaries in Paris, in other smaller cities they are even less.. i agree and I already see at my scale a salary increase in average, probably in the right direction.

</comment></comment></comment></comment><comment><USER5> Pretty near exactly how I did mine also, and we've raised almost the exact same amount. Surprisingly good post.

</comment><comment><USER6> The segmentation of VCs by the author seems to occur on a few axes: attitude, interest levels in early startups, response time, interest in exit strategies, partner quality as board member, fund phase/timeline, network quality.

The book _Venture Deals_ is a good resource.</comment>


Uber, Lyft Poised to Lose Fight Against CA Bill to Label Drivers Employees - <AUTHOR> https://www.wsj.com/articles/uber-lyft-poised-to-lose-fight-against-california-bill-to-label-drivers-employees-11568069041?mod=rsswn <comment><USER2> I don't understand why the term ride-sharing is even used when talking about Uber and Lyft. Has anyone ever gone with a driver who wasn't just driving an unlicensed cab? Or is it referring to multiple riders sharing one car?

<comment><USER3> All the Ubers/Lyfts I've used (between 30 and 40 as rough estimate) are people in what looks like their own cars. There's never been any cab insignia anywhere on them.

<comment><USER2> Unlicensed cab as in: driving people from point A -> point B with the purpose of making money, without having a taxi license.

</comment></comment></comment><comment><USER4> The opponents of this bill claim that they would need to institute shifts. Why so? Why can't they just be part-time employees with flexible schedules?

<comment><USER5> If all drivers are employees and all show up to work at 10AM when there is little demand, you can't pay all of them minimum wage. The companies would have to predict demand and ask just enough driver employees to match the demand.

<comment><USER6> Why does "employee" equate to "show up at 10AM" ? Why cant they work the same hours and style they do now, but with the title of "employee"?

That's an honest question, I know employment laws are complex and likely didnt include these concepts, but I'm also interested in facts over speculation.

<comment><USER4> You are correct. They could. This comes down to offering a minimum income to people who work for Uber and Lyft and giving them benefits that they would otherwise never qualify for like paid health insurance.

</comment></comment></comment></comment><comment><USER7> While I like better prices through competition, I think the employees should be treated fairly.

<comment><USER8> At some point the race to the bottom to exploit workers has to stop.

</comment></comment><comment><USER9> So all freelancing companies also should follow the same route?

<comment><USER10> With the kind of freelancing you are probably referencing, the deal is that you get a much higher hourly rate with the drawback that you have less long term job security and need to actively manage your engagements, contracts, taxes, etc.

Ride sharing drivers usually get less money than "normal" drivers, to the point where legislators around the world want to protect them.</comment></comment>


Summarizing two years of experience marketing my websites - <AUTHOR>

I wrote a blogpost to summarize all my experince in website marketing, hth<p>http://karim-ouda.blogspot.com/2012/06/15-steps-to-promote-your-new-website.html <comment><USER2> Looks like good material! Clickable link: [http://karim- ouda.blogspot.com/2012/06/15-steps-to-promote-y...](http://karim- ouda.blogspot.com/2012/06/15-steps-to-promote-your-new-website.html)</comment>


Space law is inadequate for the boom in human activity there - <AUTHOR> https://www.economist.com/international/2019/07/17/space-law-is-inadequate-for-the-boom-in-human-activity-there <comment><USER2> This is a duplicate of [https://news.ycombinator.com/item?id=20468768](https://news.ycombinator.com/item?id=20468768)

</comment><comment><USER3> Duplicate.

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

</comment><comment><USER4> I love the audacity of humans setting up laws to regulate space. Hilarious levels of hubris.

<comment><USER5> We setup laws to regulate everything else. It's all intersubjective. How is this any different?

</comment></comment><comment><USER6> We need a huge artificial moon in a close orbit to corral all the space junk into rings.</comment>


"O.M.G" acronym traced to 1917 - <AUTHOR> http://hnn.us/blogs/entries/137852.html

<comment><USER2> How marvelous. This guy sounds like just the sort of person who would say "OMG", too. Maybe scholars should comb through his letters looking for "I was like".</comment>


C++ Versus Objective-C   - <AUTHOR> http://www.mactech.com/articles/mactech/Vol.13/13.03/CandObjectiveCCompared/index.html

<comment><USER2> I hate Obj-C with a fiery passion. My single biggest issue with it is that it simply does not make my life as a programmer any easier. On the other hand when I work in C# I am constantly amazed at how damned easy the language and the libraries make my life.

Not once when using Obj-C have I ever said, "Wow, that was so easy thanks to Obj-C!!!" I am more likely to curse the heavens as to why the debugger can't show me the contents of any basic container type.

Going forward my work will be as heavily cross-platform C++ as I can make it. The UI may be done through platform native interface constructs, but everything I can possibly make C++ I will.

<comment><USER3> What you care to provide an example? Are you referring to not being able to mouse over a var during debugging and having it displayed properly? I've never minded having to use gdb to type out "po items", but can understand that if you're used to mousing over and getting vars it would be annoying.

I don't disregard your perspective, mine is just exactly the opposite (I would prefer ObjC/Cocoa to C++/<Framework of your choice>, no contest).

<comment><USER2> My perspective is one of a PC/console game background who works on iOS stuff on the side. The transition from VisualStudio/C++ to Xcode/Obj-C is eye stabbingly awful.

Obj-C can absolutely accomplish most anything that C++ can, but I don't think the language makes of it easier. Once you've learned that GDB even exists and figured out many of the strange syntax nuances it's passable, but in my opinion not easier.

By comparison going from C++ to C#, Lua, or Python (my personal experiences) is astonishingly easy. Not just easy at first but continuously surprising at how many wonderful things you can do and how easy it is. As I said in my root post not once have I ever said "holy shit Obj-C sure made this task easy!"

<comment><USER4> >Once you've learned that GDB even exists and figured out many of the strange syntax nuances it's passable, but in my opinion not easier.

You can mouse over an NSArray or NSDictionary and see its size and contents. You're not as familiar with the tools.

I have your same complaint, but about C++. I'm frustrated that I can't easily see the contents of a std:set or std:map in xcode. I'd be thrilled to find out if it's just a gap in my knowledge, though.

<comment><USER2> An NSMutableArray full of nothing but NSStrings will not display the string values of those strings on either mouse over or the locals view. I can see the number of strings but not what those strings actually are.

:(

</comment></comment></comment></comment></comment><comment><USER5> I've never really programmed in C++, but I have to say (as an iOS developer who's programmed in Java, Basic, C# in the past) I love Objective-C. It's really easy to write good, object-oriënted code in the language and it got so much better with the release of iOS 5 and the new SDK, especially because of ARC. I'm not sure if C++ has anything comparable to ARC.

<comment><USER6> I wasn't sure what ARC is: It means Automatic Reference Counting. <http://clang.llvm.org/docs/AutomaticReferenceCounting.html>

In C++, you have std::shared_ptr (or boost::shared_ptr and many others) which do automatic reference counting (although you specify it explicitly that these pointers have automatic reference counting; there is no way to simply enable it for all raw pointer types).

</comment></comment><comment><USER7> This is an interesting (though incredibly dated study) from an academic standpoint because both languages are supersets of C and represent two different lineages (Simula vs. Smalltalk). That said a more modern and useful study might be a set of comparisons between Objective-C and Java, since they are the current mobile dev languages of choice.

<comment><USER8> > This is an interesting (though incredibly dated study) from an academic > standpoint because both languages are supersets of C

Technically, C++ is not a superset of C. And each new release of either language has them get more incompatible with one another.

</comment></comment><comment><USER9> The thing that this 1997 is missing is the retain - release mechanism, found "only" in classes, that are derived from in NSObject, and still a key Obj-C feature.

I don't really know when exactly was this added to NeXT/Cocoa API, but I think it's important to note.

</comment><comment><USER10> If this is a contest - then I declare "No Contest".

C++ is a standards based language available across multiple platforms and the other one isn't.

<comment><USER11> Objective C is available anywhere GCC is available (i.e., essentially everywhere).

<comment><USER12> How I wish this were true. For example, lack of Objective-C and Foundation in NaCl is my primary barrier to using it.

[https://developers.google.com/native- client/faq#ProgrammingL...](https://developers.google.com/native- client/faq#ProgrammingLanguageSupport)

<comment><USER13> Is there any actual incompatibility that prevents building an Objective-C runtime for NaCl, or is it simply a matter of ObjC not being included by default?

<comment><USER12> I've been thinking (warning: pure speculation ahead) that I could target my binaries to LLVM IR and then use the highly-experimental PNaCL. But who knows how long it will be before that is viable.

</comment></comment></comment></comment></comment><comment><USER14> The lack of destructors and constructors makes Objective C miss an entire galaxy of functionality. That the language authors and programmers don't sorely miss this feature is a testimony to the limited understanding they have of programming. Lack of destruct-when-I-leave-scope makes real exception semantics impossible, and no "smart" objects that clean up after themselves meaning it's impossible to create abstract data types with such limited features. Programmers who don't miss these features I call "flat programmers" because they are missing an entire dimension in their code. They are forever having to understand the details of their implementations instead of being able to package up functionality from initialization to destruction in abstract terms. Don't bother trying to explain any of this to them. People don't understand what they don't understand. They don't even know what they are missing. But I suppose this is appropriate for Apple programmers who are more concerned about which pixels appear in a drop down list box than the overall job their program is attempting to do.

<comment><USER15> This must be the 9001st time I read a post by a C++ programmer that doesn't understand that the problem isn't that other languages don't have RAII. The problem is that C++ doesn't have finally/unwind-protect and thus requires RAII to approximate it.

<comment><USER16> I would use RAII even if it weren't required for C++ exception safety. RAII is _convenient_ and it allows you to write code that is smaller and more solid than it would otherwise be (with or without a "finally").

<comment><USER8> > RAII is convenient and it allows you to write code that is smaller and more > solid than it would otherwise be (with or without a "finally").

You don't know what `unwind-protect` is now do you?

<comment><USER17> I've looked over what unwind-protect does and to me it doesn't do more than what you can do with a custom RAII like class.

The key thing is that it acts like a wrapper around a try/catch/finally-like block (including other forms of flow control), while allowing you to put arbitrary code in the execute and cleanup portions. You would get the same effect with RAII, most of it would be taken care of for you with the right RAII classes, and if you needed custom code then just write a custom RAII like class or be smart about handling it.

Although the C++ version wouldn't handle C's longjmp and also goto's. But if you use them you're not exactly coding in C++ then.

<comment><USER16> Not just longjmp and goto, but Objective-C's @throw.

As much as I'm a fan of RAII in C++, it really is a "pure C++" idiom. If a C++ class is needed in Objective-C code that can @throw an NSException, then the C++ cleanup code really has to be invocable explicitly (because the destructor might _not_ be called). For example:

      MyCPlusPlusObject object;
      @try
      {
        ...
      }
      @finally
      {
        object.cleanup();
      }</comment></comment></comment></comment></comment></comment>


Show HN: A Thing I Made For NaNoWriMo - <AUTHOR> http://dnoel.ca/post/33597346182/a-thing-i-made-for-nanowrimo

<comment><USER2> Ooh, I also made a thing for NaNoWriMo! Namely, a way to force yourself to spread out the writing over the whole month instead of pulling all-nighters at the end to try to catch back up.

<http://blog.beeminder.com/nanowrimo>

</comment><comment><USER3> Really cool. Similar to writespace for google chrome, which I use sometimes.

FYI your facebook sign in link isn't working for me. (Chrome) ALso, if it syncs to google.. why can't we sign in with google?

<comment><AUTHOR> Thanks! And hrmm, will look into that... thought I checked it in Chrome. What OS are you on?

I stuck to FB (despite the flack that it will certainly garner from this community) because the initial goal was to take advantage of the social graph for collecting feedback (send the story to select FB friends for feedback, they annotate it, you see all their comments in one place and next to the relevant sections). I still hope to implement that feature at some point, and it's a lot easier if I don't have to maintain my own graph (which would be fun... but this is just a little "weekend" project).

EDIT: The bug you referred to is new, and happening across browsers. (I didn't notice it because I don't log out enough.) Something to do with the HTML5 app cache, I think. Refreshing the page after signing up "fixes" it, but I'll be working on a proper fix ASAP.

EDIT 2: Bug fixed :) (Wasn't HTML5 app cache at all--FB API issue.)

<comment><USER3> Sign-in isn't working for me still. It's just text - not a link. (OS X, Chrome)

<comment><AUTHOR> Bizarre, I can't reproduce that (although that text link is what appeared with the old bug). I wonder if it's a server caching issue? I'm assuming you have JS enabled?

Either way, thanks for letting me know. I'll keep digging.</comment></comment></comment></comment>


Database development mistakes made by application developers - <AUTHOR> http://stackoverflow.com/questions/621884/database-development-mistakes-made-by-application-developers/ <comment><USER2> I never understood the groans of dismay from other developers when the subject of writing SQL comes up. I'm a dyed-in-the-wool application developer, but I _love_ writing SQL.

Unlike HTML & CSS, which seem designed to spread into a greater morass of obtuse and interdependant hacks with every trial-and-error iteration, SQL has always felt elegant to me.

It takes just as much time to craft an SQL query as it does to translate a design into HTML/CSS, but 99% of the time I can sit back and be proud of my handiwork; even re-using it later.

On the other hand, I have never completed a webpage without looking at the resulting markup and thinking, "What an ugly goddamn kluge." SASS and JQuery and HTML5 and CSS3 don't make a difference. Maybe I'm just bad at it, though.

I eschew ORMs at every opportunity, and it is mysterious to me why "writes SQL for you" is such a common "feature." I would liken it to a tool which "paints paintings for you" or "designs your app for you." Why would I entrust a computer program to do something which requires the creative spark of a human?

<comment><USER3> I like the relational algebra underlying SQL. I don't like the clunky syntax, or the weak type system, or the lack of a good composition mechanism. Agreed that HTML and CSS are even worse!

<comment><USER2> By "lack of a good composition mechanism," are you referring to the trappings of writing and dealing with SQL syntax itself? As in, "Ugh. I decided to change this join into a subquery, and now my @#$#% parentheses are imbalanced!"?

If so, I agree strongly, but I feel like that problem could be solved by better error reporting on the part of the compiler. I dread SQL errors now, at least with Oracle (which I work with the most often), because they almost _never_ tell me what I need to know. To a certain extent it's essential to the abstraction of data reporting itself, but certain errors are just comically vague.

<comment><USER3> Not really, I'm referring more to the ability to factor out common patterns and compose them together to make queries, etc.

</comment></comment></comment></comment><comment><USER4> For what it's worth, here's a few from me

 _Indexes_. Everybody says it, but I'm still surprised at the number of devs who have next to no idea about index and how they work.

Few guides: Every index adds a write penalty, so don't just add them to everything. If you've got a compound index, it will only be used if the query also uses all the fields in the index (If you build an index on surname, firstname and dob, but execute select * from users where firstname="Bob" and surname="Jones", the index won't be used). Benchmark the difference each index makes, and stand back in awe at the improvement a few well places indexes can contribute.

[Edit: as pointed out below, my experience is well out of date and it looks like there's a number of database engines where the compound index thing doesn't apply]

 _Learn to think in sets_. Most devs are used to operating on discrete pieces of data; we're not used to thinking in sets, and so writing efficient SQL doesn't come naturally. Put in the effort and learn it and you'll be well rewarded. SQL is built around sets of data, and can almost assuredly do stuff faster than your code can. Hint: anytime you find yourself getting the result of a query, iterating over the result set and executing another query for each result _you're doing it wrong_

 _Learn how your ORM works_. If you're using an ORM (and most of us do), learn how to use it efficiently. This is where having a good working knowledge of SQL helps, because you can then find out how to help your ORM create good SQL. If you're using ActiveRecord, understand how to correctly use :conditions, :include etc, and what they're doing behind the scenes. Ideally you want your ORM to make one call to the DB, and to retrieve everything you need in that one call (calls are expensive, even for very small queries). Poorly written code causes the DB to get hit constantly. Not good,

<comment><USER5> > (If you build an index on surname, firstname and dob, but execute select * > from users where firstname="Bob" and surname="Jones", the index won't be > used).

I don't believe that's true, at least not for all RDBMS. I just checked the docs for MySQL and PostgreSQL and they seem to agree with me.

[http://dev.mysql.com/doc/refman/5.0/en/multiple-column- index...](http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html) | "The name index is an index over the last_name and first_name columns. The index can be used for queries that specify values in a known range for last_name, or for both last_name and first_name."

[http://www.postgresql.org/docs/8.2/static/indexes- multicolum...](http://www.postgresql.org/docs/8.2/static/indexes- multicolumn.html) | "A multicolumn B-tree index can be used with query conditions that involve any subset of the index's columns, but the index is most efficient when there are constraints on the leading (leftmost) columns"

<comment><USER6> If we want to 100% correct, indexes don't just hurt writes, and they don't hurt all writes either. Two examples (there are more):

\- If I do an UPDATE query, and I don't modify indexed columns, the index doesn't need to be modified.

\- If I have indexes on (last_name, first_name) _and_ (last_name) the (last_name) index is redundant. Some queries may use the last_name index when I don't specify the first_name - but they could have used the other index. Now I have bloated what contents need to be memory resident (affecting reads as well).

<comment><USER7> I'd say that suggesting there's a "penalty" at all implies a naive hardware setup[1].

Total system I/O is a finite resource, but this can be hard to reach if indexes are on separate spindles[2] from the data and each other. This can cost substantially more initially, but disappears at scale.

Perhaps, then, as for the OP's original topic, one mistake is not hiring someone who knows these performance strategies. Another is using an RDBMS that doesn't support them.

[1] which, granted, is far and away the norm

[2] or sets of spindles, or SSDs

</comment></comment></comment></comment><comment><USER8> Don't know if this was mentioned in the answers (haven't read them all):

Don't assume that once you make your query run perfectly it will stay that way for ever. Once row count grows, your query might start to perform very poorly. Happened to me just recently, when a query was running in the 0.0001s range, but over night crawled to a halt and took 1 minute(!) to execute. Always pay attention to your querys and monitor if anyone of them is starting to slow down.

<comment><USER9> Are there wrappers for database APIs which log the time spent on each query?

<comment><USER10> The MySQL slow query log could be of use. Of course you don't get a stack trace this way but it's essentially free (as in built already and not a huge performance hit).

<comment><USER11> Problem I have with this log is that legitimately slow queries, in my case usually those where I have concatenated 100's or 1000's or inserts into one query, make it hard to use in a meaningful way.

It's possible I'm using it wrong, did get much past trying it out. Fairly easy to roll my own rough timer in a DB wrapper, haven't got around to finishing this yet though.

</comment></comment></comment></comment><comment><USER12> Also: don't make assumptions about how you believe a database works, just because you've used another one (or another version of the same).

And measure every optimization you make, too :) I saw someone doing an optimization that should have accelerated the processing, only to discover once in production it was 4x slower.

</comment><comment><USER10> My addition to the already great list: using temporary tables to serve content. Temp tables are great when you have a complex report, and breaking things up into stages gives you a performance boost (think you need to do multiple lookups against a list of users that is small but takes a long time to build). So if you generate this report at midnight via a cron job, temp tables work great. However, generating a bunch of them at once is a performance hit. Instead, use indecies or (in the worst case) caching with triggers.

</comment><comment><USER13> Very good points. I have bookmarked the Stackoverflow post. I am glad that I had a good teacher for this subject in college. I really can't stress enough how important it is to design your database properly. I personally think that designing the database structure is one of the most difficult things to do when starting out a project. It is also the most fun :D Also, the satisfaction of optimizing your queries with just a few tweaks and seeing large amounts of improvements feels very good.

I love SQL and find it easy to solve problems with it. But I feel the opposite for ORMs. It adds another "learning barrier" for me. I hate it because sometimes I know how to solve a problem in SQL but have a really hard time solving it using the ORMs syntax. I have my doubts on it because at the start of the project you are supposed to define what DB you will be using.

Also, am I the only one who wasted countless hours trying to figure out how to execute a query using an ORM? While being absolutely sure how to do it with SQL?

This is my current situation. I am not that experienced and have a lot to learn. That is why I will be spending more time learning the ORMs I will be using and more hours figuring it out :)

</comment><comment><USER14> I started in database development in 1995ish. Surprised to see an article like this detailing the exact same problems we had back then. Our solution was to have classroom sessions with developers, to provide them with the education they wanted/needed. Biggest problem back then was the use of embedded SQL rather than stored procedures.

<comment><USER15> I was going to post the exact same thing. I started in '99 and am shocked, shocked to see this is still an ongoing issue. I thought by now most devs had at least read a little Codd, Date, and/or Pascal.

Maybe it comes from having started building web and db apps for large enterprises where the DB was the nucleus of the operation and the apps the satellites. It seems among the web crowd it's the opposite - the app is the nucleus, with the DB and presentation layer the satellites, resulting in ORM among other things.

In those enterprises, access to the DB's was strictly controlled by the DBA team and data made available to apps via stored procs only. The app devs would request a stored proc with certain parameters that would return a certain dataset, and the DBA team would implement it and grant access to that app only (or grant access to an already-existing sp that did the same thing).

The idea of ORM still bugs me for that reason, even though I use it anyway. I can't help but suspect it's the formalization of a convenient but bad practice. I could be wrong about that though, biased as I am in this regard.

<comment><USER16> > It seems among the web crowd it's the opposite - the app is the nucleus, > with the DB and presentation layer the satellites, resulting in ORM among > other things.

Indeed, this is one of the strongly-held "opinions" of Ruby on Rails. The database is more or less treated with contempt, a mere bitbucket.

</comment></comment></comment><comment><USER17> #1 on my list: don't assume your application is the only one that will ever need access to your data. PUT YOUR DATA IN YOUR DATABASE.

#2: don't put stuff that aren't true facts into your database -- just because it's a reliable cross-process data store does NOT mean it's appropriate for all cross-process data sharing.

#3: don't fall in love with SQL. It fucking sucks.

</comment><comment><USER18> A sort of hack I use sometimes (clearly documented) is to avoid joins when dealing with large data, mainly if caching is not an option (it should be but, hey, I found out it's not always like that!).

Say you have a table for people and another for cities where they currently live at. If you were to do this for a small country you won't deal with many different cities so a join won't waste much time. But if you're using all the countries in the world then the number of cities is really big. When that happens, use two different and simple queries: one to get all the people, another to get all the cities. Then just check if both entries exist on your sets and use them on a while or for-each loop. It can be a big improvement.

Note: This is a really simple example which isn't the best case scenario for this tip. Think large sets with lots of joins between them.

<comment><USER19> Can you explain this some more? You don't really list what you're trying to achieve in your example and I can't think of a case where looping over a large data set in code is better than querying against it.

<comment><USER18> I believe it's not easy to explain but let me try again and if it doesn't work and you are really interested in it drop me a line by email and I try with some more complex examples, ok?

Once I had this problem with a calendar on some application from a client. It was a month calendar and for every day there were some conditions that needed to be verified: is it an holiday?, is it fully scheduled?, is there at least one person available that day?, and so on.

How was it working? Well, for every day it would query the database for each one of those conditions which would in the end sum up to 5 minutes since it was a not so small dataset.

So how could we fix this? I started with the usual approach, let's just try to get this done in one query and some joins. There was some improvement but it as a messy query full of joins and even some sub-queries. It took something like 20 seconds to load that calendar and that wasn't enough.

Next approach: divide the most complex joins and sub-queries in some really simple queries. Examples: get a set of all the holidays, get a set of all the fully booked days, etc. Then, when you loop to show the calendar you just check if the iterating day is on the holidays set, then on the next one until you find one that works; if you don't just leave it blank. This made the calendar loading right away.

Benefits: cleaner and (much) quicker code (and also easier to cache if you can, just cache each query individually since some of them don't change that often, like holidays).

Is it making any sense now?

<comment><USER19> This is much clearer thank you. From your initial example, I thought you were suggesting to just load 2 large tables into memory at once and iterate through them to find matches.

Also, at the surface, this seems like it would be a good application for using materialized views. I obviously don't know the ins and outs of what the usage here was, but this seems like a case where slowing down the insert would be a good speed sacrifice for retrieval.

I'm not going to even feign being an expert at database optimization, but that seems like it might be a more efficient way to approach it.

<comment><USER18> I actually didn't know about materialized views but from what I've read it seems like this wouldn't be a good place to put it to work just because the conditions on the calendar where changed pretty frequently (most of them weren't, like I said on my previous post, but some were and from that I read that could be a problem since the view needed to be updated frequently).

It feels really good to learn something new, I'm thinking of some scenarios which might improve with this type of views, thanks!

</comment></comment></comment></comment></comment><comment><USER20> A suggestion to use surrogate keys instead of natural ones doesn't seem right to me. IMO proper choice of natural keys leads to better mapping from a knowledge domain into the corresponding relational model; if you are unable to find natural keys maybe there's something wrong with your database schema?

<comment><USER21> Not being able to find a natural key isn't why you use a surrogate. You use a surrogate because natural keys are not static: they can change. Surrogate allows you to have a key that is unrelated to the data, data that will change. Basing keys on changing data is risky.

I've experienced this myself, and while natural keys do work in theory, in practice, they are prone to failure.

<comment><USER17> ON UPDATE CASCADE. Tis a pity it's not more widely implemented.

<comment><USER21> Which does nothing for anything utilizing the resource itself outside the database. I'm not referring at all to keeping the database consistent. Having something you can always refer to to grab the same data is invaluable.

<comment><USER17> Fair enough. I'm more worried about database consistency -- it's just the way I roll, I guess.

<comment><USER21> I'm all for database consistency. It's just not only database consistency that I'm worried about. I've just been burned by keys that were also data before. Having keys that aren't related at all to the data just hurts a few sensibilities and a few individuals sense of calm. =)

</comment></comment></comment></comment></comment></comment><comment><USER22> Interesting list, have a few good points, unfortunately some points are personal opinions rather than universally agreed practices.

</comment><comment><USER23> _6\. Not simplifying complex queries through views_

Number 6 needs to be used with discretion.

When you reference a complex view, you are in essence making use of a stored query snippet -- there is no magic to the view, and unless you've materialized it (which is very rare), there is no efficiency advantage. All it really is is code sharing.

So what's the problem then?

The problem then is that the query analyzer has to assume that you actually care about every element of said view, every returned column, every spurious join. I've dealt with too many performance problems where people made use of an overly generous view that invalidated most indexes, removed the potential for covering indexes (the #1 most important performance element of a database), and did a lot of joins that were irrelevant to the usage.

<comment><USER24> 6 and 13 (use IN not OR) really rely on the optimizer doing its job and can hide some nasty performance issues. I do know one release of Sybase would freak on IN but be fine for an OR (have no idea why). Also, views where very dicey.

</comment></comment><comment><USER25> Given the rise of NoSQL solutions and the amazing lack of query runtime optimization performed by most relational DBs, looking at this list made me ask "why even bother?"

<comment><USER2> There's a yawning chasm of difference between "a query that gets the right data in the right way, but does it somewhat inefficiently," and "a query that gets the right data in a stupendously roundabout way." For the former, query optimization is a reasonable salve. For the latter, no amount of automated optimization can save you from crippling performance problems.

Look at it this way: If someone comes to you and says, "I want to get from New York to California in 2 hours, so I'm going to take a 747." Off the top of your head, you could tell them, "I don't think you can do that without a Concord." A computer could easily optimize that plan.

But if someone says, "I want to get from New York to California in 2 hours, so I'm going to stick grapes in my nostrils and soak my shoes in canola oil," there's nothing you can do to help this person, because they clearly have no idea where to even start. A computer could do no better.

Using _or_ instead of _in()_ is taking a 747 instead of a Concord. But many of the points in that article, like using _distinct_ to mask a lack of understanding about how you're asking for data, are very much the grapes & canola-oil-Nike's of SQL.

 _EDIT_ : Whoops. Sorry; since you had been downvoted, I misread the gray-on- light-gray text as "Given the amazing amount of run-time query optimization performed by most relational DBs." Guess I should have run my comment through an HN Post Optimizer.

NoSQL solutions are not a drop-in replacement for relational databases, either, though. They're different tools for different jobs.

No matter what, you're going to need to look at the same data in different ways. If that isn't true, then the decision is easy. But in pretty much every non-trivial application I've ever worked with, the source information and the requirements for the resulting data format have never been the same for every feature.

When you decide to go with NoSQL, you are implicitly accepting some of the burden previously handled by the RDBMS: The onus is now on you to do your own "indexing," your own "views," your own "normalization." I only have experience with CouchDB, which provides an excellent array of tools for handling these responsibilities, but for certain types of data, there is still no substitute for an RDBMS.

<comment><USER26> The more I use CouchDB the more I see it as something that complements "traditional" relational database features.

I'm actually rather hoping that someone produces a hybrid NoSQL-SQL system that gives the best of both worlds.</comment></comment></comment>


Cheating in Programming - <AUTHOR> https://twitter.com/ben_burnes/status/1178676970609139712 <comment><USER2> All of this is clearly a matter of balance.

If you were to have infinite time, you would be idiotic to _not_ spend a bunch of time fully internalizing the entire stack; or at least, trying to comprehend as much as possible given your non-infinite memory. Hell, whilst you're at it, throw in a rounded education in the humanities and sprinkle a ton of socialization in there too.

But you don't have infinite time. So instead, you try to find the balance that allows you to perform the task you wish to perform.

And at that point it's a completely personal decision. Perhaps you spend more on soft skills because you have managerial aspirations. Perhaps you drill down into bit banging simply because it's of intrinsic interest to you.

There probably is some basic level that's useful for every programmer to have, sure, but what that even means is dependent on sector. I don't know a thing* about Windows because it's both highly uninteresting to me, but also because it'd be a waste of time for me to bother with it. (Perhaps the two are linked!)

* okay, I know a decent amount compared to the man on the Clapham omnibus, but not compared to a Windows developer

<comment><USER3> I love the infinite time explanation. It's a great way to explain how/why tradeoffs are made. I haven't been able to put it so succinctly, so, uhhh... that's mine now I'm stealing it. Please credit me in your original post.

<comment><USER2> You would have come up with it but you were too busy doing something else.

<comment><USER3> Such is life

</comment></comment></comment></comment><comment><USER4> Writing original code is laborious, extremely time consuming and in many scenarios unjustified (for majority of coders). It is not an excuse for ignorance but originality in coding isn't particularly productive (IMHO).

I am reminded of an old post (from HN I think) in similar vein that stuck on with me [https://stackoverflow.com/questions/153234/how-deep-are- your...](https://stackoverflow.com/questions/153234/how-deep-are-your-unit- tests/153565#153565)

I do take time to understand the code I am using, but for most part spend finding the code (and libraries) I want to use even in the simplest cases. I've developed a habit to give credit in my code ... in fact I have an expansion ';c' on my mac for giving credit! :-)

I see a lot of very experienced programmers spend time writing and debugging even simple lines of code which are perhaps completely obvious to them. I think it is just that way coding is. It is perhaps very difficult to get it "First Time Right".

I guess its a balance between getting things to work vs. self-gratification.

<comment><USER5> I'm curious about your expansion. What application are you using and how did you set it up?

<comment><USER4> I use TextExpander. I wanted to do some custom stuff and discovered this recently [federico-terzi/espanso: Cross-platform Text Expander written in Rust]([https://github.com/federico-terzi/espanso](https://github.com/federico- terzi/espanso))

I tried espanso a bit and it seemed to work pretty well and is customizable.

</comment></comment></comment><comment><USER6> It's important to know "enough" about the lower level details to accomplish the task.

But the whole economic point of Divison of Labour[1] is that the effort is dispersed, no?

Knowing "enough" means that, for example, I don't

\- use a page of Java to load two tables,

\- put their keys into assiciative arrays

\- loop through the arrays and build a list of unmatched keys

. . .when a single SQL statement can give me the Venn diagram output of the two sets. (Really saw that in some code.)

[1] [https://en.m.wikipedia.org/wiki/Division_of_labour](https://en.m.wikipedia.org/wiki/Division_of_labour)

</comment><comment><USER7> I used to think the same with music and programming but I stopped caring at some point.

In my spare time I find joy in writing things from scratch but I see it more as challenging myself rather than "not cheating"

If I write a compiler purely to challenge myself, I'm much more confident in using an existing one in the future. However with a cheating/not cheating mindset I'd be reinventing the wheel every time.

</comment><comment><USER8> I agree with the gist of the quote ("you're not a real x unless you do y" is silly). But it lacks nuance. From what I got to see, a lot of programmers never bother what's happening underneath their code. For them, Spring, node.js etc. will always be magical black boxes. Here's another analogy for you: Would you go to a doctor that knows how to remove an appendix, but doesn't know how the circulatory system works?

<comment><USER9> So what? You don't understand what's going on inside your CPU because at this point they're too complex for anyone to fully know, and probably your understanding of the OS is on an as-needed basis. Why hold others to a different standard.

<comment><USER10> Correct. A surgeon or gastrointerologist might only have an understanding of the circulatory system insofar as it helps their surgeries and gastrointestinal work.

So yeah, I'd probably go to a doctor who's really good at removing appendixes over the guy with comprehensive medical knowledge.

<comment><USER11> Doctors all acquire broad medical knowledge as part of their training. They're not allowed to specialise until they've shown adequate competence in basic general medicine.

An eye specialist who is absolutely clueless about heart or kidney function would be unusual, and not particularly useful. Not only do most drugs have multi-system side-effects, but many conditions affect multiple systems.

So Dr Appendix Removal will almost certainly do all kinds of surgery.

Consultants tend to have a more limited focus, but you don't get to be a consultant without doing a lot of other medicine first. Usually they either work as supervisors/managers, or they're called on to consult/advise and maybe operate on more challenging cases.

<comment><USER10> Yes I know the reality of the situation.

So let's rephrase. Do you trust an AI controlled robot specialized in appendix removal (with a very good track record) but zero knowledge of other systems or procedures?

<comment><USER12> Why _would_ it have zero knowledge of other systems? Unlike people, you can just upload the information to it over high speed interface.

<comment><USER13> Surgeons spend a lot of time studying. Its not like some employers in tech that expect the dev to operate on different kind of patients all day long with 100% productivity and no prior training except what they already knew from school. So information is constantly being uploaded. But developers need to rely on abstractions because the field is constantly changing. After 10 years a framework would be obsolete or undergone major changes. Meanwhile the human evolution won't change much in 10 years although there will be a lot of new research the anatomy stays the same.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> School teaches us that reusing someone elses code is cheating, and using a library would be cheating in a work interview. But using a library is actually standard practice, even when you are paid per hour. Doing anything from scratch will take a lot or research and or trail and error. Even basic stuff we take for granted, like putting text on the screen. eg fonts Unicode graphical driver, etc.

<comment><USER14> However, is this how we get into situations like npm, with everyone using other people's libraries and having so much bloat? Where is the balance if any? I don't have an opinion either way, just putting it out for discussion.

<comment><USER13> I will write here that you should use libraries. Then next week you will see me complain about an app having two million dependencies... Here's how I find balance: I try to use "battle tested" code rather then writing my own. eg. other people's libraries. But I try to keep the dependencies down. If a package has 10,000 files I rather just rip out the functionality I need. (So I hate when you can not do that, eg. if every function in the code is dependent on every other function.) Often I find issues and are either too lazy to send a "merge request" or the maintainer refuse to merge it. So in many dependencies I often end up using my own fork.

Dependencies are a two edges sword. It's good that you get security updates. But if you can't review all the changes, security issues can also sneak in. Like if someones npm account get hacked and the hacker sneaks in a remote shell or backdoor. Those can be hard to find if you got millions of dependencies which get tons of updates every day. So I usually lock down dependencies, and NPM becomes a fancy tool for copy/pasting.

</comment></comment></comment><comment><USER15> Isn't "cheating" already a well solved problem? The only way you can cheat is by using code you didn't write without the owner's permission. If you violate someone's Copyright you're "cheating". Let's take an extreme example. Your product is just a 1:1 copy of an existing product like IntelliJ with a reskin. You're cheating if you haven't negotiated a license with JetBrains but if you do have such a license and sell an identical product then you are not cheating.

There is no shame in using a library or tool to solve a problem that you do not understand. A "real" software engineer knows when it makes sense to outsource the work to an existing tool or write their own.

When you have to interoperate with other programs through an open standard then it may be counterproductive to write the code yourself. I've personally seen way too many hand written CSV parsers/writers that were just plain wrong.

</comment><comment><USER16> That's the problem I have when making a toy project from scratch in order to learn a technique (be it databases, blockchain, or deep learning). I'm always wondering if I'm allowed to use such algorithm or clone such github repo. Or if copy/pasting an auxiliary function is cheating or not.

To avoid such moral dilemmas I try to come up with projects that solve a new problem (which also comes with its own set of challenges). And then use all the means at my disposal.

As a bonus it also keeps me motivated, since it has a shot at being a profitable business idea.

<comment><USER10> Green lumber fallacy. You don't need to know much of anything about lumber and trees to be a good commodities trader.

Likewise, you don't need to know the exact algorithmic details of something if you're still achieving your desired outcomes.

If you're not getting the outcome you want, you need to dig deeper into the components you don't fully understand to get them to perform as expected.

Real life results are best judged on metrics one step removed from the work.

<comment><USER17> My favorite quote from work, somewhat apropos:

"I know people making good money trading corn who would be shocked to learn that it's a plant."

</comment></comment></comment><comment><USER18> Looping isn't "cheating" if you know what you're doing. But if you blindly do that from the beginning without ever learning how rhythm really works, then you're going to be lost when things get more complicated.

And the same is true of the dev who copies tons of code from stack overflow without really understanding it. When issues like thread safety of the app come up, that dev is going to be lost.

Experienced musicians choose loops and samples understanding full well the trade-offs of quantization and timbre. Experienced devs bring in libraries understanding the trade-offs. Answering the question "how well do I need to know this library before introducing it in production?" is a really, really hard problem.

In practice, I see junior devs blindly copying code that subtly won't work more than I see them writing their own DI system because of not-invented-here syndrome. But, admittedly, the latter tends to be more destructive.

<comment><USER9> You've got to start somewhere, why not learn quote-unquote "deeper" skills on an as-needed basis.

<comment><USER10> This is the difference between an enthusiast and a professional.

The enthusiast can afford to learn the "deeper" stuff first, then move up.

The professional needs to know enough to ship a safe, stable, on time product.

</comment></comment></comment><comment><USER19> Coming from a gamedev perspective, I've personally decided to draw the line at the following for my projects:

* Using your platform's graphics/sound/input/etc. APIs, or wrappers like SDL, is not cheating

* Using a third-party engine is cheating

Other programmers may draw the line elsewhere and that's fine. I think for me it's a question of, using a library to achieve <hard task> is fine, but using a framework puts on me the burden of understanding and then extending someone else's half-completed program. And when that someone else made a decision that I wouldn't have made that fucks with my workflow, it also puts on me the burden of, is it okay to go in and change it or implement a low-level hackaround? Or is _that_ cheating, and should I do everything in the framework's own terms?

<comment><USER20> I don't think players care about the architectural purity of your product.

Some baseline of performance is sufficient as long as you can deliver the proper experience, which is really the only thing they're seeking in your game. If that same experience can be delivered MUCH more quickly and easier why would someone deny themselves and their users those benefits?

I understand there is nuance in this decision but it feels dangerous as a hard and fast rule. I think especially so when team size > 1-2 and common understanding becomes important.

<comment><USER21> > I don't think players care about the architectural purity of your product.

But we can kinda see how the "quick and easy" approach with modern engines is leading to lots and lots of sloppy games with leaky seams.

I always appreciate it when a gamedev writes their own engine, and IME these tend to come out as the more polished games. Doing your own engine would also enable open sourcing it, which is something gamers can be quite grateful for 10-20 years down the road.

<comment><USER22> > _I always appreciate it when a gamedev writes their own engine, and IME > these tend to come out as the more polished games._

Of the ones that finish perhaps.

</comment></comment></comment></comment><comment><USER23> Reminds me of the following quote:

> If you wish to make an apple pie from scratch, you must first invent the > universe.

\- Carl Sagan

</comment><comment><USER24> In my Web programming class in college, our final project was to make use of everything we learned to create a website. In class we didn't get past chapter 9. I however, read and completed all chapters. I made use of Ajax and a webserver which was only taught in chapter 12.

Fast forward two years, the teacher is trying to run the project to showcase an example project her students can do. She can't run it. She remembered it being a great project, but now for some reason some parts won't work.

I get a call to come help them. I dust up the old project, edit it, and get it running in front of the whole class. "What was the issue?" She asks.

"I used a webserver, now I hardcoded all the data since it's just a demo"

"Oh, so you guys cheated?"

Long story short, I was threatened to get my grade revoked, but because I have made things right I was forgiven.

As far as school is concerned, I cheated.

<comment><USER25> I don't get it (probably neither do you). Was using the webserber what she considered cheating? If so, why? You said it was covered in Chapter 12. If it was part of the course, why would it be considered cheating?

<comment><USER24> Because webservers were not covered in class.

<comment><USER25> So basically the rationale was, because you studied on your own, over what was covered in class, you cheated? Way to incentivize learning...

</comment></comment></comment></comment><comment><USER26> Perhaps this is link is better than a blurry screenshot (of HN): [https://news.ycombinator.com/item?id=11083296](https://news.ycombinator.com/item?id=11083296)

</comment><comment><USER27> Ok, so this is actually a topic which I've been thinking about quite a lot over the years.

Back in college there was naturally a strong emphasis on writing your own code, after all, you're supposed to be learning. In the end, we had to roll out everything on our own - rarely, if ever, did we get to use libraries or frameworks.

They were extremely strict on plagiarism too, so you were constantly afraid of your code getting flagged (for whatever reason).

All of this really created a mindset that using libraries = cheating. Same with looking up help on the web.

It took me years to get rid of that mindset, simply because it didn't feel right.

<comment><USER28> Were you allowed to use a compiler?

If so, you weren't writing your own code. You were just writing a description of the code in some human oriented programming language, and the compiler wrote the actual code for you.

Also, the compiler almost certainly linked in a runtime library - more code you didn't write.

But let's skip the compiler and its runtime, and even any assembler, and just write raw binary machine code.

Now you're writing your own code, right?

Well... On any modern processor, your so-called "machine code" is just a high level language that the processor compiles into its own internal operations - which don't look anything like your machine code and don't even get executed in the same order. So you're not writing the code the machine runs.

You could avoid this issue by writing code for an older processor like the 6502, where your code bits go straight into the logic circuitry as is.

In fact, that would be a darn good idea - you would learn a lot doing it!

<comment><USER29> No, no. Compilers don't _write_ (their own) code, they _translate_ (our) code.

<comment><USER30> > No, no. Compilers don't write (their own) code, they translate (our) code.

No, no. Developers don't write (their own) code, they simply translate the (customer's) specifications.

<comment><USER31> > simply translate the (customer's) specifications.

LOL no! If I did that my customers would go out of business.

</comment></comment></comment></comment></comment><comment><USER32> We hired a guy who 'made cool games'. They weren't really fun, they were buggy, and they were all made with Unity.

We also hired a guy who made simpler Javascript games, but his code looked great an he understood how it all worked.

One is still here, and isn't very useful, the other left for greener pastures as management wanted him to work on only the boring stuff.

<comment><USER33> What's your take-away?

<comment><USER34> To me its: If you do a good job with simple tools you'll be given boring work. If you work in cool technology you get to work with cool technology even if you're producing junk.

<comment><USER35> I rather interpret it as "If you do a good job with simple tools you'll be given opportunities." (I'm interpreting the parent post to be implying that the simpler, solid hire is the one who is no longer there because they were able to leave for a better place). Also, as cautionary tale for managers: "If you give folks who write solid code boring work, they _will_ find something that suits them better."

</comment></comment></comment></comment><comment><USER36> Can't see the original tweet, is it deleted or did the user just block me for some reason?

<comment><USER37> I guess deleted, can't see it as well

</comment></comment><comment><USER38> I think part of the issue is in knowing how you would go about learning and implementing a thing. There is a lot of code that I don't need to bother writing because someone else has done it, but I could write it if I needed to, or could learn the algorithms and implement it. A programmer who has a breadth of knowledge and general understanding of how they would go about writing Node.Js will do a lot of things in Node.js a lot better, especially optimizing. I could figure out how to write a lot of software. And when I see something, I can usually run through which language, architecture, etc. to make it. That's useful.

</comment><comment><USER39> How about copy/paste from Stack Overflow? Is that cheating?

Most of the code I write these days is put together like a ransom note but it sure makes it easier to get things done.

</comment><comment><USER40> I also think using loops is cheating so I only use gotos.

<comment><USER41> Sounds like cheating to me no less. You unroll the loops to uncheat.

<comment><USER40> Guess I'm still a cheating bastard.

</comment></comment></comment><comment><USER42> This comment is shared around for a couple of years now, but finally sourced it from Splice's Facebook at; [https://www.facebook.com/spliceofficial/photos/a.55520699121...](https://www.facebook.com/spliceofficial/photos/a.555206991212765/679408552125941/?type=1&theater)

</comment><comment><USER43> That's a really poor analogy. This guy is making equivelant tools to tools that already exist. When someone chooses not to use a framework, they don't rewrite the framework, they write something more specific to their needs.

</comment><comment><USER44> I thought it was about coding. I remember doing some paging data entry screens with FoxPRO (generating screen form code then adding in additional code to handle the paging), and letting another user know how to do it on a forum, and I got a "That's cheating" response. heh.

</comment><comment><USER45> Calculator-in-the-pocket problem. Why learn if we can externalize memory, etc.

Of course application becomes the concern, but can we really be assured that someone who can perform the calculations mentally also knows when best to use them?

</comment><comment><USER46> Interesting. I've been heard that there should be no 'black magic' since I just tried to do something in this field. But yes, everytime I cheat more or less, though. So what's the standard here?

</comment><comment><USER47> I like making music with computers.

You can draw the line where you want at a concert.

If you only need some background music for vocals, press play and be done with it.

If you are good enough to play something live while singing, you can gradually change the way.

</comment><comment><USER48> I think the sweet spot is knowing enough to know how something works, in essence, if not how to do it necessarily yourself without a whole bunch of bootstrapping.

</comment><comment><USER49> The problem is not cheating, but that abstractions _leak_.

</comment><comment><USER50> I don't think that cheating exists, unless you are prosecuted for it. For example, you don't fail a final for cheating, you fail a final for being caught doing something that someone paid by the Uni thinks is cheating. So unless you are punished by an active authority, you have not cheated. And thus, you can't cheat at software unless you are censured for it!

</comment><comment><USER51> People that thought this way use to be referred to as a "hipster".

</comment><comment><USER52> Rule of thumb: You should only include code that you could write yourself if you took the time. Otherwise you don't understand your own software.

<comment><USER53> According to this, I don't think any of us (or a very small percent) understand our software.

</comment></comment><comment><USER54> twitter - someone else's platitudes with additional useless commentary.

</comment><comment><USER55> Put simply.

Life is an optimization problem.

</comment><comment><USER56> And Bike-shedding ensues...

</comment><comment><USER57> cmd+f yak shaving. hmm.

</comment><comment><USER58> There is, as always, a relevant xkcd: [https://xkcd.com/378/](https://xkcd.com/378/)

</comment><comment><USER59> Obligatory XKCD: Real Programmers.

[https://www.xkcd.com/378/](https://www.xkcd.com/378/)

</comment><comment><USER60> Seems like this is about "cheating" in music.

<comment><USER61> I'm sure you're aware of the word "analogy", right?</comment></comment>


Human Head Transplants Just Several Years Away - <AUTHOR> http://bigthink.com/ideafeed/human-head-transplants-just-several-years-away <comment><USER2> Shouldn't this be body transplants? I mean, the identity of the post- transplant person will presumably be that of the head, not the rest of the body.

</comment><comment><USER3> I felt really sorry for the monkey mentioned in the article.</comment>


California ordered to disclose students' protected personal information - <AUTHOR> http://www.cde.ca.gov/nr/ne/yr16/yr16rel15.asp <comment><AUTHOR> Quoting from the court order: "Failure either to submit a Objection Form or letter to the Court by April 1, 2016 will be deemed a waiver of your right to object to the disclosure of your or your child's protected personal information and records as described above."

And yet it doesn't actually say that "objecting" will prevent them from disclosing anything.</comment>


10% of Americans don't use the internet. Who are they? - <AUTHOR> https://www.pewresearch.org/fact-tank/2019/04/22/some-americans-dont-use-the-internet-who-are-they/ <comment><USER2> Looking at the infographic[0], it appears be down to advantage/privilege. These people would have less capital resources to be able to afford service and, of course, those living in rural areas would have a much higher propensity to _not_ have the utilities offered in their area(1).

(1) - Added to that should be the consideration that the current design of much of the internet infers that it would be futile to attempt to access it over dial-up.

[0] - [https://www.pewresearch.org/wp- content/uploads/2019/04/FT_19...](https://www.pewresearch.org/wp- content/uploads/2019/04/FT_19.04.22_NonInternetUsers_bar.png)

<comment><USER3> In that infographic, age seems to be as strongly correlated as income or education, if not more strongly. 0% of those age 18-29 (of any income or education) don't use the Internet.

<comment><USER2> Aye, I concede that it probably also constitutes confusion around the definition of "use of internet". As another commenter pointed out, Thailand's statistics are askewed with 45% saying they use Facebook but only something like 36% saying that they have internet. Mobile Phone connectivity, for example, mightn't fall under people's definition of "using the internet"; so, there _is_ that consideration to be made.

<comment><USER4> I don't know about Thailand but in the Philippines many phone plans only offer a few sites.

</comment></comment></comment></comment><comment><USER5> Can't use the Internet if you don't know how to read.

<comment><USER6> Exactly. Seems like the question is answered by the bar charts: mostly people aged 65+ without high school education.

</comment></comment><comment><USER7> I question this result, since:

[https://qz.com/333313/milliions-of-facebook-users-have-no- id...](https://qz.com/333313/milliions-of-facebook-users-have-no-idea-theyre- using-the-internet/)

tl;dr: In Thailand, 45-ish percent of people say they use facebook, 30-ish percent say they use the internet.

</comment><comment><USER8> They are the forgotten and the number should be higher

Older people like my parents. There is the afraid of technology group.</comment>


Apache Wicket – three years of lessons learned - <AUTHOR> http://blog.bosch-si.com/apache-wicket-lessons-learned/

<comment><USER2> Wicket is a single design flaw:

-no clean dependency injection possible due to the "page" life cycle

-inheritence hell out of the box with coder kiddies thinking adding even more subclasses would be "clean" and maintainable

\- excessive round-trips required in the build and test cycle

\- breaking Maven conventions w.r.t to resources and Java classes which f###'s up Eclipse workspaces

Compare this against Bootstrap and a lightweight server-side implementation which can be learned in a fraction of time compared to Wicket's "different" approach.

great "design"

<comment><AUTHOR> Which light-weight server-side frameworks you would recommend then? apache click? I could not find any which is popular.

<comment><USER2> BTW: one more thing which I initially did not mention is that Wicket generates a hell lot of client-side code with loads of nested DIVs (per component probably), weird and long wicket IDs which tell you nothing (they are automatically created). Pretty tough to get used to - especially for someone trying to understand what happens "under the hood".

<comment><AUTHOR> Thank you. I was under the impression that Spring MVC (actually Spring, in general) requires a lot of XML configuration. But, maybe it's the best bet now. I checked out Play 2.0. It's a nice framework, but documentation is sparse, which is a show-stopper for a newbie like me.

</comment></comment></comment></comment><comment><USER3> Server died. Here's the Google cache version: [http://webcache.googleusercontent.com/search?q=cache:-UXdDxO...](http://webcache.googleusercontent.com/search?q=cache:-UXdDxOD6t8J:blog.bosch- si.com/apache-wicket-lessons-learned/&hl=en&gl=us&prmd=imvns&strip=1)</comment>


How Can A Free Conference Call Be Free? - <AUTHOR> http://feefighters.com/blog/how-are-free-conference-calls-free/

<comment><USER2> Reminds me of a very similar story from Austria.

Back story: Austria is one of the most competitive countries as far as mobile phone plans go. There were three big companies, A1 (previously state-owned, a bit similar to AT&T), One (now Orange, owned by French Telecom) and Max (now T-Mobile, owned by German Telecom). In 2003 a new company, Hutchinson 3 (branded as "Drei") emerged. Backed by (for a small country like Austria) seemingly unlimited money from Hutchison Whampoa they built a completely new network (again: Austria is pretty small). They only cared about getting customers and started a price dumping war with the other three players.

In 2007 Hutchison 3G introduced a new kind of mobile plan called Sixback. Because of the - in their opinion - high termination fees they offered 6 (Euro-)cents per minute on incoming calls from the three other providers. In Europe you don't pay for incoming calls like you do in America, but getting paid for incoming calls was new. The plan became quite popular, there have been reports of peoply having over two dozen SIM cards from other providers just so they could "load" their Sixback plan using the free minutes from the other plans and then transferring the money via a 0900 number. (0900 is the area code for phone sex and similar numbers where you pay a lot of money per minute and the receiver of the call receives most of that money).

Of course the other providers hated Hutchison 3 for that plan, but that quickly turned around when the regulation body lowered the termination fee, so that every Sixback call now loses money for Hutchison 3. They don't offer that plan anymore, but there are lots of customers who still have that plan and obviously refuse to be switched to a newer plan.

</comment><comment><USER3> Interesting, I dint know that.

I had an interesting experience with ATT. I was into the 6 month of a 2year contract back in 2007. I wasn't using my phone much (non-iphone). But then I went on a road trip to Yellowstone, which included driving through ND, SD, MT and WY. During this 7 day trip, I was using my phone a lot (work + personal). The total amount of minutes I spent in those 7 days were way more than my usual monthly usage (in fact it ate into my rollover minutes as well).

After a few days from returning, I received a letter from ATT telling me that they could not afford me on their network for using so many minutes, as they had to pay their _partner_ n/w in those states (not just major cities in those states). They wanted me to leave their network, in return they would let me have the phone (under contract for free).

I was happy to oblige as I wanted an iphone. I switched to Tmobile for a week and then went back to ATT again (iphone plan).

<comment><USER4> FWIW - AT&T is now in SD. (grew up there, and still have family in the state).

<comment><USER5> And in Montana as well when they purchased Alltel in 2009.

<comment><USER6> I was getting ready to correct you, when I researched the Alltel acquistion.

Verizon purchased Alltel, but was required by the FCC to sell off 105 of the markets, which is where ATT stepped in and bought a bunch of those markets.

FWIW, my Alltel account was switched over to Verizon in 2009.

</comment></comment></comment></comment><comment><USER7> This type of scam is big business in rural Iowa (and I'm sure other areas).

I used to work in rural northwest Iowa. We had a "programmer" (to use it loosely) quit to work for a company who's sole purpose was to abuse this system.

They ran a "phone company" in a small town and then connected a big asterisk box at their local exchange to accept free conference calls. They then installed smaller asterisk boxes in other businesses that were a long-distance call away with for the sole purpose of keeping the lines coming into their conference box 95% full 24x7 with bogus calls from 5-45 minutes long.

<comment><USER8> phone line arbitrage. brilliant!

</comment></comment><comment><USER9> Bear with me here, but it seems to me like this is a good argument for socialism.

Consider: why do termination fees exist? Clearly, as America was being wired with telephone service, the cost to run lines to rural areas was prohibitively expensive. So what's the capitalist/Randian thing to do? Well, charge more for phone service out there. If people can't afford it, then they'll move to where it is cheaper to have a phone line, right?

Except you have to consider _why_ people would live in these rural areas to begin with. For a large number of individuals, they are probably farmers (or involved in food production). If they have to pay higher rates for phone lines, then they would have to raise the price of food to make living in rural areas viable. But there's obviously a _really big_ incentive to the government and everyone that's not living in rural areas to _not_ have the cost of food increase. So what does America do?

To remain somewhat loyal to pristine capitalist ideas, America decides that it's going to let competition and corporate interests resolve the issue, but to make things "fair", the government will put its finger on the scales, just a bit. Unfortunately, when you forget to take your finger off the scales, then you end up with AT&T spending $250mil unnecessarily!

Efficiency of the market, eh?

Of course, a more socialist-leaning country would've just had the government pay to install rural phone lines.

<comment><USER10> So a government acts socialist, distorts the market, causes damage, and you think this is an argument for _more_ socialism?

All starting from the unwarranted assumption that telephone access was necessary to farmers and food prices would have risen dramatically.

<comment><USER11> _"All starting from the unwarranted assumption that telephone access was necessary to farmers and food prices would have risen dramatically."_

Yeah, that initial assumption really is weird.

How much could a phone line like that possibly cost for a company who does phone lines? I have no idea, maybe 10 million for all I know.

But that's a one-time cost that will be spread out over _all_ the crops that farm produces for the next however many years that telephone line lasts. With some (admittedly ~10 years out of date) idea of some of the other costs involved in farming, I have a hard time seeing the bump to food prices being anything to get your undies in a twist about.

<comment><USER12> Some googling around gets me a cost of $120,000/mile to install overhead telephone wire. So, for example, if you have a tiny town of 200 people that's 15 miles away from anywhere, running a phone line out to it will cost $9,000 per resident. Which sounds steep, but possible to self-fund.

On the other hand, if you have one guy on a farm two miles away from the next nearest neighbor, well, adding a phone line costs as much as building a second house.

The interesting question for society is, should these people have phone lines? And if they should, how much of the cost should they bear themselves? And how far should we be willing to go to run phone out to increasingly remote areas?

<comment><USER13> This conversation goes rather differently in the age of the mobile phone.

<comment><USER14> Mobile phone base stations aren't free either.

<comment><USER13> Certainly they are not. But you have more deployment options, and while 15 miles of phone line run to a single customer benefits only the customer (and, I suppose, everyone else who might want to reach them) a single cell tower has potential benefits to the entire subscriber base.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> A similar thing happened in New Zealand (and likely elsewhere) in the late 90's, before broadband became prevalent. There were a number of ISP's who provided free dial-up internet, because they made money from termination fees when the majority of people called from a large telco to their smaller one. Eventually the large telco reached a commercial agreement and the service was scrapped, but it was good while it lasted.

<comment><USER16> Same thing in Ireland, except that we paid for the calls. So we paid 2c per minute, of which the ISP maybe 1c got from the telco in termination fees, so there was a lot of "free" internet access at the time.

<comment><USER17> Same in Brazil, where free ISPs owned by small telcos in the then-recently deregulated market were incredibly important in making the Internet popular during the 90's. The free ISPs became so good that they started competing with for-pay ISP at every level, including speed.

Of course broadband made the whole thing obsolete.

</comment></comment></comment><comment><USER18> AT&T and Google Voice had a dispute over this a few years ago because AT&T must terminate all calls and GV was blocking calls to the freeconferencecall.com numbers.

[http://arstechnica.com/tech-policy/news/2009/10/att- accused-...](http://arstechnica.com/tech-policy/news/2009/10/att-accused-of- regulatory-capitalism-as-fcc-probes-google-voice.ars)

</comment><comment><USER19> Getting rid of the regulation altogether seems like tossing out the baby with the bathwater. It seems like it would be possible to correct by removing the loophole of routing calls through a rural region that are not terminating at a resident of that actual region. I don't understand telephony enough to know whether that's a simple thing to detect or not, though.

<comment><USER20> It's not a simple thing to detect. Short of broad-scale wiretapping, if I bridge two calls on my office phone nobody will know except my in-house PBX. The telco sees two simultaneous calls into my PBX, but unless they are actively listening in on both lines, they can only guess whether these two callers are also talking to each other.

<comment><USER19> I suspected it might be something like that. Thanks for clarifying.

</comment></comment></comment><comment><USER21> This is all true. One technicality though is that Google Voice is not a VOIP solution (yet) which is why the fight with ATT over terminating rural calls is interesting.

<comment><USER22> _Google Voice is not a VOIP solution_

Isn't it? I can make calls from my laptop microphone. What else do you need to be VOIP?

<comment><USER23> I think the clarification is that it is not _just_ a VOIP service. If I call someone with my Android phone it is routed through normal voice call paths, not as a VOIP call.

</comment></comment></comment><comment><USER24> I once read that this is how MagicJack makes most of their money as well.

<comment><USER25> It's interesting that you bring you MagicJack. I have always wondered how they made money. Now it is starting to make some sense. Can you share the link to that article?

<comment><USER26> This article ([http://www.telecomlawmonitor.com/2011/04/articles/access- cha...](http://www.telecomlawmonitor.com/2011/04/articles/access-charges/fcc- rules-voip-provider-may-not-collect-access-charges/)) explains th FCC decision against the company for trying to exploit this model.

</comment></comment></comment><comment><USER27> This seems like a good example of SEO-driven linkbait.

It's not quite spam -- the story is interesting, if not exactly breaking news -- but I'm pretty sure the main goal is to get inbound links to feefighters.com

<comment><USER28> Inbound links are the indirect goal of every blogger. I found the article to be very informative about the details of a business segment I wasn't familiar with. What makes this article different than others?

<comment><USER27> People blog for many different reasons. I would argue that posts written to generate linkbacks and boost page rank are actually relatively unusual. I think most blog posts are either written to directly promote something on-site or to bring in direct revenue through ad impressions or because, ya know, the person just has a story to tell or an ego to stroke.

</comment></comment></comment><comment><USER29> Even though the high cost to setup the lines have been collected, it's still expensive to maintain these lines so some version of this needs to be in place.

My solution would be to figure out what it costs annually to maintain this and limit the fees imposed on other companies to this fee. At the end of the year you calculate the percentage of calls your company terminated to the area and pay that percentage of the fixed fee.

</comment><comment><USER30> That explains why I can never connect using Vonage.

Thanks. I always wondered about this, but not enough to dig into the details. Interesting.

<comment><USER31> It bothers me that the VOIP providers don't, say, play a special message explaining the issue. If it's not illegal for them to block these numbers, then why not at least explain themselves? Perhaps they could offer at-cost connections? "Press 1 if you are willing to pay $0.08/minute for this call"

<comment><USER30> I agree that a message would be helpful. I've learned to blindly accept it as an isolated technical issue. I'm accustomed to grabbing my cell for conference calls now.

</comment></comment></comment><comment><USER32> As VOIP becomes more common, I've found that some people consider it rude to use these free services. Things have shifted from a VOIP setup not being a proper phone because it can't connect with these numbers, to these numbers not being proper conferencing because VOIP users can't call them.

</comment><comment><USER33> So... AT&T is suing Google to force them to pay these antiquated fees as well?

Why wouldn't they use their combined legal power to abolish the fees together, instead of fighting each other?

Because sure, at some point, Google may easily be forced to pay them too.

</comment><comment><USER34> Pretty fascinating...the OP describes the regulation as "outdated"...but are there rural companies that depend on it? Or is it truly outdated and due for a change?

<comment><USER35> It's outdated in the sense that the original reason for the high fees was to make it economically viable to provide service to people in rural areas. But the original sunk costs of wiring every home and business have long been paid off, and the digital-ization of the phone network has drastically reduced the ongoing costs of providing service to those folks. So it's outdated.

On the other hand, there are plenty of local CLECs in rural areas that make money from these fees, and they continue to lobby hard to keep the tarriffs and fees as they are.

So it's both, really.

<comment><USER36> Further, the phone call itself does not have to physically terminate in the locality the rate center represents. For instance, a free conference calling service's VoIP servers may be hosted anywhere (e.g. AWS), not necessarily in Iowa. Thus, the reason the Telecommunications Act of 1996 provided for this type of compensation is non-existant in this type of VoIP scenario.

</comment></comment></comment><comment><USER37> Here's a 2007 article explaining this:

[http://pcworld.about.net/od/webtelephonyconferencing/FCC- ref...](http://pcworld.about.net/od/webtelephonyconferencing/FCC-referees- dispute-over-free.htm)

</comment><comment><USER38> So, given all this, why wouldn't AT&T offer a competing free conference service where they keep the termination fee?

<comment><USER39> AT&T already has a conferencing business; why should they jeopardize it when they can just crush their "illegal" competitors? It's just like why Hollywood won't fight piracy by lowering prices.

</comment></comment><comment><USER40> Related: Cameras May Open Up the Board Room to Hackers — NYTimes

< [http://www.nytimes.com/2012/01/23/technology/flaws-in- videoc...](http://www.nytimes.com/2012/01/23/technology/flaws-in- videoconferencing-systems-put-boardrooms-at-risk.html) >

<comment><USER40> _Un_ related?</comment></comment>


A Very Tough Day (Redfin lays off 20% of staff due to economy) - <AUTHOR> http://blog.redfin.com/blog/2008/10/a_very_tough_day.html

<comment><USER2> Redfin doesn't have a real business model that works. There are more obvious solutions needed for the real estate industry that would be less likely to fail.</comment>


Show HN: Fabrik – Portfolio builder for creatives - <AUTHOR> https://getfabrik.com/

<comment><AUTHOR> Hi HN, been working on this for the past year, bootstrapped with two other founders:

Fabrik is a SaaS-based portfolio platform designed for creatives. Our CMS completely separates project content from website styling, allowing creatives to easily add their work, blog, and build responsive websites without touching any code. Intelligent themes, partnered with layouts and customisation, make each portfolio one of a kind.

Our mission is to help creatives (both fresh and experienced) to find a way to get their work out into the world and get noticed - to maintain a solid foundation on which to showcase their portfolios.

Really hope you like it. I'm here to answer any questions.

<comment><USER2> I don't really like your page: Lot's of what feels like wasted space, too much scrolling necessary.

I can't figure out the pricing except that it is "free for 14 days".

The front page shows a picture of a woman, but then a male name as an example?

The actual pages for the users look very nice though (better than the other way round IMHO ;)) Very image heavy, but I guess that's normal in the industry.

<comment><AUTHOR> At the moment Fabrik is an annual subscription at a cost of £69 ($105) but we're hoping to get monthly billing up very shortly - couple of weeks or so.

We showcase Fabrik Heroes on the homepage of the site. These are creatives that use Fabrik. Supporting our community is very important to us.

We have a tour page if it helps you find more information on the product side of Fabrik: [https://getfabrik.com/tour](https://getfabrik.com/tour)

</comment></comment></comment><comment><USER3> Visually it looks good (though confusing at times and can't seem to read the text) but I am wondering what your goal is for posting on HN? (i.e. get feedback on how it looks, customer acquisition, etc.) Just wanted to make sure what your intent was before I make comments.

<comment><AUTHOR> I'm looking for exposure, and support really. We have no budget for PR and a product like this needs to be used to be properly understood, so i'd really love for people here to try it out, give the CMS a go, see what they think about it.

There are some onboarding shortcomings, which I think is understandable with such a small team, but we're making it a little bit better each day.

Obviously the members of HN understand products and startups, so I welcome all comments and feedback on how it looks, but more importantly, how it works.</comment></comment>