LukaAl

The idea is amazing. I just wonder if he had also implemented the Chromosomal Crossover in the "sex" function. From his description of the results it seems so, but he hadn't described it and it seems an interesting part to explain.

Ok, probably was just me but when I saw in the title the words "Severity" and "Critical" with the site being openssl.org I thought: "OMG, here we go again".

I tried both and i prefer Redis over Memcached except for very simple use cases. It is true that for a pure caching system Memcached is easier to setup, easier to scale and faster. But by just a small margin. On the opposite side, Redis provide a lot of primitive very fast and implemented in C that allow for more complex use cases. For instance, in one of the project I was following, the ability to merge two or more sorted set was pivotal in implementing a more efficient warm-up scheme. I could get the same result with Memcached and a software layer, but it would be less efficient in term of latency and bandwidth. Given these huge advantages, my choice is almost always Redis because I prefer to manage one system instead of two.

> Right now, I feel I could do maybe 15 peoples jobs.

I don't know you, so I'm not sure, but in my experience you are wrong. I understand where you came from, being a co-founder myself I know at the beginning you have to do the jobs of 15 or more people so you still believe you are as good as them.

But there are two problems:

- You should hire someone that is better than you. Even if you are the best in your field, you should hire someone that could possibly replace you.

- In almost every non menial job, you need to keep your skills updated. You cannot keep up with 15 different jobs and still run a company with 15 people. So after few months you are no more as good as them.

Be aware, you should understand the job of the people you manage. It is ok to ask them why they made some choice, it is ok to challenge them in a respectful way. But they probably know better. It is not just a morale problem, it is a specific problem.

When you become a manager, your task is no more doing their jobs. Your task is to help them become better at doing their jobs. (The next step is to become a leader, where you simply inspire). I saw a lot of managers at different levels (startup CEOs, mid-level manager) failing because they believe they are better at their jobs than their employees.

Having a little bit of experience in the telco industry, I could really say a lot of this topic even without knowing the details of the hacks.

For instance on the IMSI catcher, from what I understood they are a form of MIM attack where a fake base station connect to your phone and forces it to switch to non-encrypted mode. Why non-encrypted mode exists? Well, in the past (20 years or more) encryption was expensive and base station huge and bulky, none believed it was a conceivable attack. So they introduced a signal to switch of encryption to increase capacity in emergency.

Now you could trick cellphone to switch to un-encrypted and intercept traffic. Why this vulnerability hasn't been closed? Many reasons, first of all even if base station are no longer configured to support this mode, they should accept unencrypted traffic for inter-operability and the same it's for phones. Furthermore, it makes a lot easier to implement devices like personal base station to enhance network coverage in buildings.

Also, there's the "next gen" bug. It is almost 8 years that telco company think about 4th gen technology, the LTE network and VoLTE. This is an paper a totally new systems built with new technology and new threat model in mind. It is not perfect but far better. The issue? Implementation took longer than expected (as usual) and none want to spend money and time in fixing something that will be replaced. Sounds familiar?

So you have retention. Being long tail means that probably the users does not open your app every day and measuring retention could be challenging.

For gauging retention I would look at two number, times the app is opened each month (per users) and average number of transactions per month per users (depending on the stage the transaction value could be irrelevant). And I would check the distribution.

Usually you could cluster users in different class (actually, segment them) and you will find a reasonable number to use as a measure for "lost customer". Every customer that doesn't use your app for more than that time, is a lost customer and you use it to calculate the churn rate.

Where you set the threshold is a judgement call, so be honest with yourself, better to estimate a slightly higher churn rate than underestimate it.

Also, understand that retention is an important measure in the long term, so don't optimize for it immediately, but it is strictly related to other important measure (for instance retention influence in a couple of way virality, and a poor retention could be a symptom of bad Product-Market fit).

P.s: the number in the article seems just examples, not number to use as a benchmark.

The problem with your question is that you don't understand retention (nor the author of the post explain it well). Retention in theory is not that I buy from your service every day. Retention is that, whenever I need your type of service, you are my first choice.

Obviously it is very difficult to measure this retention, so you measure returning users. But you have to understand your market.

This said, paying for keeping users is not unheard of. Discounts for loyal customer, targeted email for new purchase etc etc...

Usually this value is factored in the LTV (Life Time Value of a customer) and you could play with it to optimize the LTV versus the cost of acquisition (Cost of retention should be lower of cost of acquisition, if it is not, look at your product/service because it sucks).

But from your original question, it seems you have a "one-off" type of service. Think about wedding planners. Your problem is that if you acquire customers faster than new customer are born, you are in trouble. Otherwise it is a sustainable business, just take care because you have an upper bound on your growth and your cost of acquisition should be lower than the profit you get in every transaction (excluded acquisition).

If it is confirmed is part of MH370, could be a news for investigations (good or bad depend on many factors). But, please, don't think this will stop conspiracy theory. Why? This is my answer as a conspiracy theorist.

"But I landed the plane on island X, How much it would take me disassemble a piece from the aircraft, hammer it a little bit to simulate an impact, and drop it in the ocean in a place where will be probably washed ashore?"

That's one of the possible answer. Than it could be: "It isn't damaged enough to be in the water for 1 year, they just soaked it and placed on the shore to be found".

I don't believe in the conspiracy theory, but please, don't think this news will debunk them (actually, it is highly improbable an object traveled so many miles, it has been set up :-) )

Yes, this is usually a problem. A better way to use cProfile is to run it and save the results in a pStat file and then, in iPython you can load the file using the Stats class [0].

With the class you could easily change the ordering without having to re-run the command (very useful when the command take several minutes). Also allows you to apply filters (cut the number of lines or apply regular expression) to the output. Usually I filter for the one/two file where most of my custom code is and I check for the hotspot; this remove all Django related calls. Then I select a good candidate for optimization and I dig that functions looking at the code (restrictions are useful in many way). It is a long process, but much less painful than you could expect. But probably it should have a well designed interface to make it easier to use.

[0] https://docs.python.org/2/library/profile.html#the-stats-cla...

Happened to me as well. Some of the eMail were just "updates" email that I like to receive but if they get lost is not a big deal. But a couple of them were very important one, and to make things worst, they were answer to email in which I was in CC. So, a colleague of mine send an email to someone and CC me. The second person answer and that mail is marked spam for me but not for the person who wrote the original eMail. Doesn't make sense that an answer to a legitimate conversation is by default a legitimate eMail?

In my experience you are wrong. Two examples, one on security the other on quality and recalls. On security, we were building an Home Gateway, the modem you have at home to access Internet. Before releasing it we realized the web page was vulnerable to a CSS attack. Since through the attack was possible to change the WiFi or the Firewall configuration we released the first version without these functionalities despite they were required by the users. The next release went through a two week pen test (consider that many of the competitors had the same CSS issue and were available on the market). Just a couple of day before releasing the new version, after the pen test was ok, I notice a phrase in the release note, I investigated a little bit and I discovered that the CSS issue was still there, it was just more difficult to reproduce (and a 2 week penetration test failed to spot it). What do I mean? That also the best security practice aren't enough to protect from all the possible issues. On product recall, same product, but on the hardware. Our hardware vendor was Chinese but we inserted in the contract strict clause on tests, product performance etc etc... After around a year we discovered that a huge product lot used a capacitor with problems and we have to recall all of them. The capacitor was produced by a reputable company and matched all the production standard when new. Lesson learned? Even if we obsessed over quality, you could have problems. The difference between a mediocre company and a good one is not that it doesn't make error, but that it is quick to solve its mistake and learn the lesson for the future.

Forecasting future is obviously impossible, but we could approach your question in a structured way.

First of all, allow me to question your premise. Software engineering is a quite lucrative job in the US in general, and in Silicon Valley more specifically. But in many European countries command average salary (with variations due to seniority, obviously). In Eastern European countries, India and China it is for sure a well paid job but not nearly as lucrative as it is in the US.

Clarified this point, the drivers of such high salaries are resource scarcity and high demand.

On the demand side, there are few relevant uncertainties: basically whether the economy will sustain the growth of the software industry (or, there is no tech bubble) and, on a longer timeline, whether evolution in programming technique will outpace the growing demand for software or not.

On the supply side, the main question is whether there will be an immigration reform or not and how it will impact the tech sector. Furthermore, more people are training now in coding than before, both in universities and after university using bootcamps or similar institutions. So the critical uncertainty is whether the new trained people are enough and good enough.

My humble opinion, given all these uncertainties and their probable resolution in the long term, is that sooner or later, "software salaries" will have to adjust downward. The only question is when and how fast. Aka, it will be something in the immediate or int the far future and it will be a hard landing or a smooth erosion over time?

Our startup is a Delaware C Corp and we are all foreign citizen. We haven't had any problem related to the fact of being foreign. On the VISA we are all on E-2 because it was easier and we avoided the lottery of the H-1B. For what I remember the point is if the H-1B holder could be fired from the company. Here are some information from the USCIS: http://www.uscis.gov/eir/visa-guide/entrepreneur-visa-guide and http://www.uscis.gov/news/public-releases-topic/business-imm.... Notice that the same point are valid for sponsoring the green card (EB visas).

Not sure about that. You assume everybody will be happy to work in GoogleDocs to write their assignment. But that's not true. If you are a commuting student you probably want to write it in an offline tool (even the notepad is fine). Also, sometimes, especially if you need to be creative, to plain old paper are a much better tool to write the first draft. Finally, I like to use a spellchecker a little bit better than the one provided by Google Docs, so I will probably run the text in it and then copy back to Google Docs. Never in my flow I cheated (unless using a spellchecker is cheating that could be true for an English class). But it will be very difficult for me to prove it because you assume cheating is using a different tool from the one you try to force me. That's not fair!

http://www.hse.gov.uk/pubns/hse8.pdf In pure oxygen some material will start combustion autonomously. But even worst, every possible cause of fire (simple friction, sparkles, etc...) that normally are not an issue, became a deadly hazard. But my point was, no, the air we breath normally is not 100% oxygen, fortunately...

Is that a joke? Normal breathable air is made of 78% nitrogen and 21% oxygen (http://en.wikipedia.org/wiki/Atmosphere_of_Earth). Thanks god is not all oxygen otherwise you will catch fire in practically 0 seconds. On the pressurization that compress your body. But the problem is, they pressurize the plane to the same level of between 3000-6000 feet. It is less then the pressure you usually feel. So doesn't make sense.

I found no number to say Yes or No but the past plans was naïve at least on this topic. A big reason for this it is that the constituency of all parties play with tax fraud.

The quote is funny but wrong. If you measure everything in ton of cash you don't understand what happens. Ratios are powerful (especially the changes over time) but are clue of something that need to be investigated. One great example, the cash ratios of Walmart were very similar to the one of broken company. Except that it was their operating model to call for having few cash on hand.

It is actually a cost and Walker is wrong. What changes is how the cost is spread. If you buy a building and you spend 1M you will have -1M cash and +1M in property. But since the building will age you will have to amortize it, let's say over 10 year. So you will account 100K as an operating expense and you will reduce the value of that building on your capital, so at the end of the year the build value is only 900K. And you do the same for the remaining 9 year. But this make sense, if I buy a building, I'm not going to use it for just one year. If you buy a company it is a little bit different. Usually the physical assets goes on the balance sheet as explained above. The difference between the buying cost and the assets is called Goodwill and it is the only part that doesn't need to be amortized. Goodwill are many things, the brand value, the internal know how etc etc and doesn't need to be amortized. But you are required to re-evaluate it every year and if it has lost value you have to write it down, so it is a cost.

If you look at it carefully, the accounting rules make perfect sense. Otherwise buying a building (or server) for my company will impact the margin of just one year and it would be difficult. The problem is that Goodwill is difficult to evaluate, so managers could decide to re-evaluate it as they want in order to boost their bottom line. But it is bad management, not bad accounting.

Regarding is point on sales, it is not even accounting, but the dumb use of financial ratios. Usually the company could use the earnings call and the notes on the balance sheet to explain this shifts. But again, it is a call on the management side to explain it and sometimes they prefer not to explain to hide from competitors. They need to find the right balance between hiding their moves from competitor and informing the investors...

The observation on failure modes is correct. When you process thousands of tasks every day even problems with low probability happens. What bugs me with the transaction approach is that you loose all the information (except probably for logs). In your example, if I signup on your service and for any reason the process fails (maybe after I received the confirmation that everything is ok) I will end up having no record stored for my account. This is problematic for post mortem diagnosis, for customer support (although its easy to ask the customer redo the signup) and so for and so on. Imagine you are handling payment with an external provider (e.g: Paypal). I could end up being billed without a trace on your system that I've paid. I'm not saying that my approach is correct. I'm saying that just assuming that transactions will save all your problems discount the fact that your system, to be useful, has side effects (not using the term in a strict way) on your customer and possibly on systems outside your organization. I prefer to plan for actively manage the possible failure modes and to detect and correct quickly anomaly. For this reason inconsistent data is sometime better than no data. Another point on the database approach that I haven't thought before: In the past we designed a system that stored and updated user timelines on MySQL. It has always been a nightmare. SQL databases are not designed with an high ratio of write operation in mind. The indexes get quickly fragmented, even deleting entries doesn't immediately deflate the disk consumption etc. I don't see this being a problem immediately applicable to a queue use case. But with your service growing in size there's a risk of hitting scalability problem. Obviously you could react like we have done, use a bigger database, use better disks, create cleanup jobs. But it is bad software engineering and you are just buying more time.

Thanks for the article, very interesting. Just one point on the solution. To my understanding, you prefer a queue implemented on a DB because transactions guarantee that a task could not start unless the task before as succeeded and committed the required data on the DB. In our environment we run tasks on RabbitMQ/Celery. One of the nice feature that I believe exists also in Sidekiq is that it allows you to create chain (or more complex structure) of task and the worker itself will take care of synchronizing them removing your problem (when a task finishes successfully it commits on the db and triggers the next step). The only problem we had where on entry points were we create the task chains and we fire them before committing the transaction. One solution was manually committing before firing the task. But that was somewhat difficult. What we have implemented was a Python decorator to have the tasks actually fired after the function completion (thus after the transaction commit). In Go we achieve the same result in a more simple way using the defer statement. In my experience, all these solutions are local to the process that fires the task, so there is less risk of interaction with other process, easy to implement and more robust compared to other solution.

There are many problems in this article. The biggest problem I see is in the value of an iPhone and in the capital that is locked while it is in transit. Although there is little information on Apple's operation, a quick look at their balance sheet provides some insights. For instance their 2014 10-K (http://www.sec.gov/Archives/edgar/data/320193/00011931251438...) list 112,258 million $ as CoGS and 2,111 million $ as inventories. These give us around 53.2 as inventory turnover or, better around 7 days. It is a very short time even for air shipping, and this value is an average of all the product. It is highly probable that Apple ships FOB destination making the choice between air and sea not important for them (or better, choosing the preferred one on other consideration). Another aspect to consider is that when the product is registered in the book is not necessarily when the product is paid for. If we take from the 10-K the Account Payable turnover ratio we get 3.7, so apples pay on average after more than 90 days. That's a pretty impressive value. So Apple put the iPhone in their inventories only when he receives them and pays them 90 days after he received them. My guess, seeing this numbers, is that the immobilized capital is not the biggest issue for Apple and their shipping strategy is a little more sophisticated. P.s: this is a quick analysis of publicly available data. If you check my calculations, you could find that I simplified them. The conclusion doesn't change if the correct formula is used.

First of all, I'm not totally sure a huge seller like Foxconn has less negotiating power with logistics company than Apple (actually is probably higher). Then, Apple could negotiate the logistics but still account the merchandise as FOB Destination. Source: negotiated this kind of deal for consumer electronic products.

Ok, now also the Mac version is twittable:

  echo 'const int main[]={1208,114434,2370306048,2101,834048,84869120,1818577091,1461743468,1684828783,10};'|cc -xc -ot -&&./t

The trick is to use retq instead of a sys call to exit and to strip some of the code that the compiler create when you call a function (pushq %rpb; moveq %rsp, %rbp; movl $0x0, eax;)

  echo 'const int main[]={3850979413,184,3234285568,33554436,29869896,1207959552,1652109,3343384576,3522,1208291072,114887,3343385088,199,1208291072,1869376613,1919899424,169960556};'>t.c&&gcc t.c&&./a.out

But it is too long to tweet

[Edit]

Less compact but more readable:

  echo 'const int main[] = { 3850979413, 184, 3234285568, 33554436, 29869896, 1207959552, 1652109, 3343384576, 3522, 1208291072, 114887, 3343385088, 199, 1208291072, 1869376613, 1919899424, 169960556};' > test.c && gcc -Wall test.c -o test && ./test

Agree on the need of powerful tool. And sometimes you ends up spending time writing the right tool for that specific tasks when it is missing (done more than one time). On your rebuttal on the tools for established industries, I just said that it's a suspicious claim, not that is false. The point is this: if an industry is a niche, usually who works in that niche has to build their own tools. In larger industries, like journalism, you think that a professional is not asked by toolmakers which feature they need to make their works faster or they don't approach themselves the toolmakers to ask for better tools? But let's see the problem from a different perspective. Could you list me an innovation that is just the application of a consolidated concept in an area to another consolidated area without a change on the underlying industry or of the technology. There's a lot of literature on this point. If you are interested, you could search for the Utterback S or the concept of paradigm shift in innovation.

I use coder because that's the term used in the question. I prefer software engineer usually. I'm not a coder, or software engineer, for what it matters but I'm doing it now and I understand how it works and I use all sort of language, from C to Python. I have no prejudice against complex editor. In my opinion everyone should be able to choose without problems the editor/IDE that prefers and that's not always true. My anecdotal evidence is that, when free to choose, the better you are at a language the more you prefer an editor. Nevertheless, I could accept your point of view, but you should explain me something, if there are different point of view you should accept that the advantage of this so called "powerful tool" is less than clear.

What do you mean for "writing tools as powerful as those used by coders"? In my experience good coders doesn't need very powerful tool. Super-complex IDE are usually a disturbance to good coders rather then an help and even the uber-geeks that use Emacs don't really use in their jobs all the macros.

A lot of good software engineer I know prefer lightweight editor like the good old Vim or SublimeText over IDE like Visual Studio, Xcode or Eclipse. That's because when you write complex code your brain is slower than your finger and the syntax and structure of the language you are using is something under your skin, you don't need to think at it.

So, no, great coder doesn't use powerful editors, if they can chose they use very simple one with the minimum level of features they need to help them think faster (syntax highlighting, autocompletion, indention) and stop. All other features of complex IDE are a disturbance rather than an help.

I don't know what a good journalist need but my guess is that they have the same problem, their brain is slower than their finger and the grammar of the language they are using should be well known. I don't know which tool they use, but in my opinion a simple text editor with a minimal spellchecking system (but not correction) well integrated with the publishing process is more than enough.

From an Innovation point of view I'm usually suspect when someone claim to have an innovative tool for an established industry. If the industry is established the actors have already optimized their tools and if there could be an improvement is very small. What usually happens is that something changes in the industry and make the actual tool obsolete (e.g: a new process or a new technology became available). But if you want to create something really innovative, you have to find this change. Simply bringing something existing in a field in a different field rarely works. And if it works is because you have a really good understanding of both fields.

What do you mean by backlog depends a lot on what you are selling: - If it is software, usually you sells it in stage or you have to deliver customization/integration at a later stage: - If it is SaaS is like before but you have also the following months of license (they usually ask for a minimum guaranteed lifetime for the SaaS); - If it is hardware for internal use usually it is installed in stage, so you could have your sales spread over few months/years. - If it is something they resell, you will have the projection of sales. _ If it is a service, you have the service not yet delivered as backlog. Obviously they can cancel when they want, but it is still your backlog until you deliver it or it is cancelled.

I've been a manager working for telco companies so I know a bit about it. Usually the backlog is a good metric but it works from when you have already sold the product. Usually to assess what happens before the sales team is asked to assess the probability of closing the deal and discount the deal size by that probability. An increase of the scope (and of the total value) or of the probability to close the deal represents your metric. It is not very scientific but could be made pretty accurate. E.g: you know the price of your product and how much you are willing to give a discount in order to close the deal. Also, even if negotiation, especially with big companies, could be unpredictable, it is usually done in steps and each steps closer means an higher chance of success. A possible sequence of steps is: - RFI received. - RFI answered. - Q&A and first meeting - Follows Up - RFP received - RFP answered - First round of Q&A/meetings - Short Listed - Second round of Q&A/meetings - Product demo - Final negotiation (usually price and conditions) This is the process for RFI, there's a different one (and a little bit more complex) for "cold calls" that probably is more applicable to startups. Obviously some steps are optional and the names could changes but this is how it works. Just a final note, though. If you are a startup in B2B avoid, at the beginning at least, big corporation as client if you can. They have a huge negotiation power, they will drive down your price like crazy and being your biggest client they will use their force to ask you a lot of extra work than the one negotiated. You will end up loosing a lot of money on the deal and also you will have little ability to follows other deals. Yes, they are useful to qualify for other clients and if you lock them in they could be quite profitable, but unless you have deep pocket they will crash your company.