mrmekon

Howdy, I'm OP! Neat to see an old blog post on HN.

1) GPL/LGPL are not incompatible with iOS, they are incompatible with the App Store. I don't care about that. I was writing a GPL'd app, and I would be pleased with a GPL'd library. iOS was also not my only target. (response to one of your other posts)

2) The idea of 'what's enough' was for e-mail decryption only. Which is what I wanted to do. And I wrote an open-source OpenPGP library to do it: https://github.com/mrmekon/libsimplepgp

3) I don't need 'some library to solve encryption and decryption', I need 'some library to solve decryption of PGP-encrypted emails.' A partial implementation of OpenPGP, as a library. Other crypto packages don't support the OpenPGP packet format.

4) Read section 4, "Packet Syntax", the entire concept behind the OpenPGP format: http://www.ietf.org/rfc/rfc2440.txt

We are completely surrounded by embedded devices, and their numbers are growing exponentially. Everything has a computer in it. You might be shocked to know the power that's in some of these devices... your cable box might be a quad-core 1.2GHz ARM.

Currently, your common options for embedded software are:

* bare-metal with C, C++, or ASM

* load a full OS (i.e. Linux) and run an interpreter to get access to higher-level languages

There are a lot of domains where the problem being solved doesn't require particularly high hardware resources, but requires quite advanced software design. Implementing something like a modern Blu-Ray player's UI and high-bandwidth/low-latency AV in C is rough. You spend a LOT up front on software development costs, and pay more in the maintenance phase. Alternatively, you can save on development and maintenance by running an OS and using high-level languages and existing libraries... but then your board price per unit skyrockets because of the extra processing power, RAM, and flash that you need to support the OS and interpreters.

Access to a modern programming language at a "bare-metal" environment is the holy grain for embedded. It would change the world.

Unfortunately, it has always been practically impossible. And likely still is.

As far as I can tell, it's a vague concept, and two "authors" who haven't authored anything asking people to help without really explaining any of the goals? Help with what, exactly?

I fully support making more languages embeddable, but this project doesn't seem to be real. I hope there's more to it than what's listed on their site right now!

I am a awful interviewee. Absolutely awful.

I routinely bomb the simplest interview quizzes. Usually the early "weed-out" ones like FizzBuzz. I do fine on the much more advanced questions.

I think part of what makes them more difficult for me is that they feel like a test. The more advanced questions, they feel like engineering problems in need of a solution. But when someone pops up with an out-of-nowhere "do this purpose-less thing!" question, I spend all of my time wondering about what they're actually looking for, and none thinking about the problem at hand. Is this a trick? Am I missing something? What does he want from me!?

I also just can't code worth a damn when someone is staring at me. I love interviewers who pose a long, complicated question and then leave the room for 30 minutes so I can work on it. These are always much more difficult problems, and I find them infinitely easier than the little 2-minute quizzes.

It seems to be more of an Internet Culture thing than a Software Developer thing. There's a huge industry of C/C++/Ada/Assembly/.NET/JVM programmers out there, behind the scenes. Many of them are working for big companies, and big ol' companies generally aren't cool with their employees even talking about what they do online. You know that old 'the opinions expressed in this blog are my own and do not represent the company I work for or their investors or their advertisers" spiel? That's considered lenient.

But the Internet likes to talk about itself, so here it seems the only world is Javascript. And this corner of the Internet likes to talk about "tech startups", which is a very broad sounding term that actually refers to a very narrow set of almost exclusively web-technology companies. Not much hardware coming out of YC.

Additionally, this is somewhat of a "get rich quick" crowd, and nothing gets you a bigger market faster than a 'web app', whatever you define that to mean. It was always hard to get the average computer user to install desktop software, let alone pay for it, and that hasn't changed much.

Short of an international software developer cold-call survey, all "language popularity" estimates are going to be weighted towards some specific community.

TIOBE seems weighted towards blog/article writers, using GitHub et al. would be weighted towards the open-source community.. Stack Overflow is also a fairly cohesive community, though a harder one to name: people who ask for help in online Q/A sites?

For instance, I'll bet that none of those three communities overlaps much with government contractors. Within the firms I've worked with, they are very, very hesitant to even use the Internet, let alone participate in it. Information comes from dead trees only. They are also staffed by a much older crowd. And they have a ton of software developers keeping Ada, C, Assembly, and Forth alive and kicking.

This dilemma isn't limited to iOS, or mobile apps. It's all user-facing software. Everything that ships to users these days -- traditional desktop software, web apps, even static blogs -- is much larger than it needs to be to achieve its functionality.

This isn't necessarily a bad thing. There's a huge tradeoff between size of the product and development speed. We've switched to a pattern of bundling lots and lots of large libraries with everything we ship, and tons of static resources, and tons of translations, and on and on. And it makes everything huge.

But it means you "full-stack engineers" can knock out full-featured, money-making web apps in hours/days/weeks instead of weeks/months/years. Most of the "look at the monetized product I wrote this weekend!" posts that show up on HN could be a fraction of their size, but would have taken much longer to develop.

The link is specifically complaining about resource files, which are probably easier to manage than libraries, but it's still probably not worth the effort for Apple. By making it as simple as possible, developers don't waste any time worrying about how they are going to structure resource usage for their app. Just throw everything in there and get on with it.

At work, I develop for platforms with <1MB of RAM, and we can do plenty with them, but development time is ridiculous. You can knock out a full online dating site in 4 hours, eh? It takes that long to print "Hello World" on a serial port of a new microprocessor... maybe longer.

My side projects are in horribly wasteful monstrosities like Python and Objective-C/Foundation because, in my spare time, I like projects to actually get finished... to hell with binary size.

My parents have been traveling to Costa Rica for their dental work for years (from the US). My dad usually stays with a local family through a language-exchange program, stays for two weeks, and takes Spanish classes at their local university.

He says he's saved tens of thousands of dollars (he doesn't have dental insurance here), and gets awesome, educational vacations out of the deal.

Even my mother, who is not adventurous at all, loves it. The dentists speak perfect English and have top-tier practices.

Seems like we all agree that USAA is awesome.

In regards to him having trouble scanning checks with Chase: that sounds like a problem with Chase's implementation, not the technology as a whole.

I have been using USAA's online service as my only form of check deposit for 5 years (started with flatbed scanner, now iphone). I have never had a check refused. Hundreds of them have gone through (have to re-take the photos sometimes, but they always eventually work). It works, and it works really well.

I agree with his suggestion that most code manipulating byte order is incorrect or unneeded. Within your application's logic, everything should already be uniform.

I agree slightly less with "computer's byte order doesn't matter", differentiated from peripheral and data stream byte order... that's the same friggin thing. It matters that you treat your inputs and outputs correctly, and how you do that depends on your computer's byte order, so they computer's byte order does matter. Just not so much during the data processing stage.

But mostly, I'm just saddened that every post about C now has a "only people who do [X thing that requires C] do that, and you're probably not one of them, so you should do that!" Maybe there's just a huge disconnect between people-who-blog and people-who-write-low-level-code, but most of the software guys I know have worked professionally on microcontrollers, DSPs, operating systems, or compilers within the last 5 years, and I'm working on a compiler for a DSP right now (and I expect byte-order to matter).

It seems like none of the projects have much finding.

Crowd-funding sites like this are likely one of those domains, like auction sites, where only the biggest few sites can really succeed. They don't work well without a huge base of funders.

Clone of the Tempest arcade game in HTML5/ClojureScript: https://github.com/mrmekon/tempest-cljs/

Competition in this market would be great for motorcyclists. GoreTex is the trick that makes replacing a car possible -- riding in the rain is no problem as long as you have waterproof gear. But a full, water-tight GoreTex riding suit is insanely expensive.

Got ~8fps increase on the Tempest game I've been working on. It went from playable in Chrome, to very playable in Chrome, and still unplayable in every other browser :(

https://github.com/mrmekon/tempest-cljs/

That's a ridiculous question, and it implies serious problems with your company's procedures.

I do a lot of "R&D" type projects that have no deadlines. But for the projects that have hard deadlines, my company has only ever missed one in our 5 years of operation.

We do this by not having any 'political' influence on schedules. Our engineers make the schedules based on information they have about the tasks. If we don't have enough information, we refuse to declare a schedule for that task.

I think a lot of companies are effectively doing research projects, and are trying to schedule them. You can't schedule learning, or creation of truly unique concepts. If a project requires research, we split the research out as a separate task and refuse to give numbers for it. Instead, we explain the approach we will follow.

I work for a B2B software consulting company, here's a tip: For one-off projects, you want an hourly rate with a not-to-exceed. Always.

Neither side gets a good deal with fixed-price contracts, no matter how nice they sound when you're thinking about throwing money at strangers. The contractor has to always throw in a significant amount of 'padding' on a fixed-price contract to account for the unknown problem that occur in every project.

The number one goal of a contractor: never, ever get stuck in a situation where you're working unbillable hours. So under-bidding a fixed-price is a big no. Which means over-bidding is required.

With fixed-price, we will also demand that the whole contract be renegotiated if anything changes. Anything. Oh, oops, you want one extra quick little feature that should only take a few hours? Fine, but the contract is being rewritten to include it and we're all going through the trouble of formalizing it.

Paying hourly is frightening when you don't know who you're hiring, but that's where a NTE comes in. We still do the schedule estimation that we would do with a fixed-price contract. We give you that as the estimate, and something like 1.5x that as the not-to-exceed price. We bill hourly, and you stop paying when the project is done. Often that is before the original estimate, and you save money. If we hit a snag, or if you decide to add a few small things, it can be handled smoothly without changing the contract. You can elect for a higher NTE, if you trust the contractor, and get more room for 'agile' development.

You define 'finished' extremely specifically, up-front, before letting them start. If you don't know what 'finished' is for your own project, there's something wrong, and you need to think about it harder. All software and documentation, delivery format, media, copyright assignment, etc should be specified.

Here's something that absolutely, absolutely critical: define at least a few milestones, at least one a week for the first month, and make sure you get them and verify they work. If their output looks good and they've been professional for the first month, you can let the frequency fall off if you wish. I have worked with tons of companies who were screwed over by contractors who took payment for 6+ months without producing anything.

My coworker from Chattanooga assures me that nobody would want to live in those neighborhoods, and that he is sending the list to friends and family to laugh about.

Not that I'm a designer or know what I'm talking about, but a few years ago I switched from doing all of my graphics work in The Gimp to all scalable vector graphics in Inkscape, and couldn't be happier.

It's a different method altogether, and skills from one don't pass to the other, but once you get the SVG tricks down you can do a lot of tremendously complicated designs with little effort, and the master copy is a breeze to work with. Modifications and post-processing manipulations become cheap operations.

It's a little unstable outside of Linux, but does run on OS X and Windows. On OS X, it crashes pretty often but recovers cleanly.

I've worked for the same small cluster of entrepreneurs, who are all very close personal friends, for my entire career. If you cold called people I'm professionally related to, and not on my list of references, then changes are very good that you're calling someone I currently work for or with. And chances are very good that my employer will find out.

Now, I have an excellent relationship with my company's owners and would certainly not get fired for such a thing, but others in my position might. And regardless, that's not information that you have any business giving out to my current employer. That's a discussion that must happen on my terms -- if my boss found out that I was interviewing other companies from your sloppy hiring practices, I would be pissed.

edit: Just realized that if you're going from LinkedIn contacts, you might be calling one of my current clients. That would be absolutely disastrous for myself and my employer -- yeah, go ahead and throw them under the bus by instilling doubt in our customers, thanks.

I'm an embedded consultant at a small firm of young guys. We use subversion, git and mercurial internally. We have project management tools, bug tracking and issue management, scheduling and time tracking and version control. We use VMware and VirtualBox to keep versioned installs of operating systems and toolchains. We're up to speed on the latest languages and frameworks, and we use whatever is right for the task at hand.

Our customers do not, in general, have any of those things. Many of them have no central version control (independent teams sometimes have subversion setup for themselves). Those who have it are usually using CVS, and usually don't use it very well.

Embedded is a field of "old fogeys" still. It isn't taught in school, it isn't advertised very well, and the companies who do it don't offer the cool perks that web companies do. A lot of these companies are running into problems where a large portion of their engineering force is retiring, and nobody is available to replace them.

This is more likely to be the case with our big customers than the smaller ones. The small ones usually have at least have some people pushing for modern project management, though it's often not implemented across the whole company.

Many of them got into the field when microcontrollers were extremely limited and C compilers were unreliable -- most of them learned assembly and used it for most of their career. There is still a tendency for the older ones to not believe us when we say their project can be written in C. Ten years ago, they would have been right.

Obviously, you can't generalize an entire industry as being "way behind", but many embedded firms just haven't progressed the same way those in other industries have.

Also, it's critical to realize that it has nothing to do with the engineers not being smart. They tend to be quite brilliant, in fact. But many of them are electrical engineers with a background in analog electronics, physics, and math, instead of modern software development.

I tried to sign up for the $150 TouchPad developer deal a few days before they stopped accepting submissions, but they never even responded.

I would never give one online service write permissions to all of my other online services.

I would consider using something like this if it were entirely self-hosted, and open-source. I already avoid single-sign-on; I would also avoid single-sign-off.

With smaller lists, the results in my test change:

  >>> t1 = timeit.Timer('copy.copy(orig)','import copy;import random;orig = [random.randint(0,255) for r in xrange(10)];')
  >>> t2 = timeit.Timer('orig[:]','import copy;import random;orig = [random.randint(0,255) for r in xrange(10)];')
  >>> t3 = timeit.Timer('list(orig)','import copy;import random;orig = [random.randint(0,255) for r in xrange(10)];')

  >>> print t1.timeit(10000)
  0.0183310508728
  >>> print t2.timeit(10000)
  0.00397896766663
  >>> print t3.timeit(10000)
  0.00760293006897

Which is similar to those results.

This implies more setup cost for copy() and list(), but after that they're faster.

Tested copy(), [:], and list():

  >>> t1 = timeit.Timer('copy.copy(orig)','import copy;import random;orig = [random.randint(0,255) for r in xrange(100000)];')
  >>> t2 = timeit.Timer('orig[:]','import copy;import random;orig = [random.randint(0,255) for r in xrange(100000)];')
  >>> t3 = timeit.Timer('list(orig)','import copy;import random;orig = [random.randint(0,255) for r in xrange(100000)];')

  >>> print t1.timeit(10000)/10000
  0.00036607401371
  >>> print t2.timeit(10000)/10000
  0.000416543197632
  >>> print t3.timeit(10000)/10000
  0.000372415995598

Probably not the world's most ideal testing here. I have no idea if/how Python caches, for instance. But slice notation continually comes out the slowest in this crummy example.

I sent this link to a coworker, and he was incapacitated for the rest of the work day. Good job!

While this is fine for the home tinkerer, an ATX power supply doesn't provide any of the basic safety features that are one of the main points of a professional lab power supply: protection against over-voltage and over-current. You really don't want your power supply to be damaged by a faulty circuit. And who knows how clean the power is.

Most people who have a use for a bench supply should also be able to figure out how to make this box for $2 instead of $45.

You can, and should, do both. It really isn't a one-or-the-other situation.

Specialize in something, but keep up your general knowledge. Being too specialized is just as big a weakness as being too generalized. Unless, that is, you become the absolute best in the world at it. Which is not something you can plan for.

Also, don't pick a specialization just because you feel like you need one, or you'll always be behind the curve. If there's nothing you are passionate about to dive deeper and deeper into, keep looking.

The two main arguments for why these articles should not be deleted are:

1) The languages exist, are supported, and are used by many users

2) There are other bad articles on wikipedia

Both of these are, unfortunately, terrible arguments.

In response to the first argument:

Wikipedia's rules state that for an article to exist, it must be proven notable by certain types of accepted references. That does not include tutorials, blog posts, software's official website, or questions on support websites/forums. These rules are unfortunate, and have been sources of much arguing, but they still stand.

We, as programmers, get upset when information that is useful to us is removed. The rules exist for a reason, though; one place where they are often enforced is the addition of video game articles. There are hundreds of thousands of video games with significant user bases. Wikipedia has made it a point that it does not intend to be a catalog of software that exists, and for that reason video game articles are deleted often. In order for software to legitimately qualify for an article, it must be significantly, demonstrably important. Existence and popularity is not enough.

In response to the second type of argument: existence of violations does not justify other violations. If don't think the blue slime from Dragon Warrior deserves its own wikipedia page, mark it for deletion and argue your point, but don't reference it as why your bad article with weak references should remain.

Wikipedia has a LOT of articles that are against its rules. We have become used to these, and depend on them, so we get upset when the rules are enforced. Have a look at the actual rules and I'll bet you can identify plenty of articles you have read that are in violation:

http://en.wikipedia.org/wiki/Wikipedia:Notability

http://en.wikipedia.org/wiki/Wikipedia:No_original_research

http://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_not

Digital versions aren't a good enough replacement for a physical textbook yet. I've used the Nook e-books (on a PC, not on a tablet), and the interface is hell to deal with. But they are fantastic supplements to the real book.

I think they would be a lot more popular if the publishers did with textbooks what record companies are doing with vinyl records: buy the textbook, get a code to download a free digital copy too.