ah no, sorry i missed that detail when reading your post

The funny thing is responsive was supposed to make life better for ipads. And so often it makes the site much worse. A simple flat scrollable page is much better than a bunch of flex-boxes.

Interesting, wasn't aware of the performance hit. React is basically reimplementing flexbox for native. I guess we'll see how well that works then

For most things, but it kind of depends on IDE. My Java WPM is probably significantly better than my text WPM because of auto-complete and a huge crap load of boilerplate that needs to be typed/generated.

I have a mechanical keyboard at work and a laptop keyboard (which I guess is low profile, fairly flat and relatively soft keys) at home with no weird setups and type pretty fast on each. I just did the default test on typingtest.com on my laptop and only got 139 but usually do ~150 on that one I think.

What's an acceptable low for programmers? I think I'd get maybe 60 typing an English text

I also think I type faster when it's brain->text compared to reading text->text (writing this post I'd guess I type 20%+ faster than I type on some typing test)

I remember that court typists or whatever they are called need 225ish WPM

I feel like I type slower on a mechanical. I took the typing test at work and I was topping out at 110, but only managed 85 at the end, which is about what I get on my laptop with scissor switches.

But they have a phonetic keyboard and don't type full words.

Think it was an autocorrect issue on my end that I didn't see until just now.

anyone with experience in iOS functional testing frameworks have recommendations?

I've used Subliminal in the past. I have nothing else to compare it to outside of UI Automation.
At the time, I knew zero Objective-C but the framework was already in place and I thought it was pretty easy to write functional/integration tests for it.

I think I've reached my upper limit. After passing 5KLOC, everything is getting very different. I honestly don't know how to go further at this point.

The best I've come up with is creating automation scripts. Basically, the script rebuilds the program from scratch and shows errors. I feel like this can work for another 2 or 3 KLOC, but I'm pretty sure it is going to fall over very soon.

Is there any resources that I can use that discusses how to deal with larger systems?

What specific kinds of problems are you having with a larger code base? One way to think about this is that you've always been programming extremely large systems - after all, your program probably has all kinds of dependencies without which it would not function, from the hardware up. Once you accept that, the key is designing the system such that parts of the system that you're not actively manipulating don't have to be actively considered, just as those who built the platforms you're programming on top of have done for you to create the illusion that you're programming small systems.

The program at this stage builds a database, makes a bunch of API calls, populates the staging tables, then converts JSON to relational data. Since there are many components, I have two levels of testing.

The first level is re-inserting into the staging tables, which involves truncating the result tables and:

The second level is full-testing, which deletes the entire database and does a full run as if it is a fresh install.

As the program gets larger, the stuff that is fully tested starts to become redundant.

Since it is getting harder to keep all of this in my mind and on paper, I'm wondering if there is better strategy here.

I was at a meetup and they were talking about continuous deployment. The basic idea was that there was three branches: the main program (ostensibly fully tested), a test branch, and a working branch.

Ideally, instead of working on one huge program, I'm thinking about how to work on a small part of the program at a time, so it matches what you are describing. I'm working on a small piece, but underneath is a large piece.

I think candybar is alluding to a Software Stack type design. This is just one example of a software stack. Notice that each level of the stack is specified in such a way that their functionality can be validated without depending on the entire system. For instance working from the bottom of the stack up, the HAL (hardware abstraction layer) provides an interface for the drivers to communicate with a hardware abstraction and that abstraction implementation is needed for each different hardware platform. So if you have a system that needs to be implemented on a different hardware platform, only the HAL needs to change. Validation of the HAL is performed in the same way for each new hardware platform. You might run full system tests but in theory once the new HAL is validated no other validation has to occur.

TCP/IP is a stacked architecture. Android, Blutooth, Windows, Linux etc. are all examples of software stacks. It is a way to manage complexity.

Right, I can see how that is supposed to work, and it makes sense. I ended up breaking apart one schema and moved a piece of code to its own file to separate the parts a little bit better.

I'm working on tiers 1, 2, and 3:

Tier 1 is simple and straight-forward.
Tier 2 depends on components of 1.
Tier 3 is where all the code is, and depends on 2.

The problem is that I don't really know what 2 looks like until I continue to work on 3, so the testing works fine for now, but I'll have to go back to 3 to finish after I have the constraints known. There are also quite a few constraints between parts of 3, so in a way, there is 3a, 3b, 3c, and those constraints aren't known until I get to 3d, 3e, 3f, etc.

Say I'm currently working on 3k, but I didn't know about 3j, and I didn't know that 3k depends on 3j, so while 3k works great, I have to add constraints to 3k on 3j to make sure all of the data has integrity, so I have to roll back to 3k to add the constraints, but I need to be sure that the parts don't create issues and conflicts.

A goal here is to not have a whole file of "ALTER TABLE" to make up for all of these issues. I'd like the base files to have all of the information, which is why I drop, recreate, the repopulate the database.

edit again: should I draw a picture?

Yes, visual views are good.

preferably in mspaint format

Pictures are good. Modeling data is hard to do mentally.

So I am starting to have to do a bunch of bit manipulation stuff at work, and haven't had a lot of experience with it. Does the code below look correct to put the lower 32 bits of dramAddress into lowAddress, and then the next 8 bits into highAddress?

I think this will work. I'd probably code it with more steps but that isn't necessary. The reason I code stuff like this with more steps is that if it is fairly complicated I can step through it and check the code out easier. Also you don't need the casts as the type conversion is implicit. Certianly it doesn't hurt though. You also don't need the leading zeros on the hex constant.

Do you even need to & this with the mask? I don't think that step is doing anything as we drop the other bits anyway.

Be careful what you joke for...

The program looks like this:



The database, conceptually, is broken up into 3 layers. The ??? Layer will be tinier than represented here, as it will mostly be look up tables, which is easy.

The "testing" area I am concerned about is the Python to the top layer, where things changed quite often. This is partly because I make mistakes, and partly because I'm not entirely familiar with the APIs.

The eBay schema, in part, looks like this:



The surprise for me was the Category Features Schema. This is a base-layer description of what can be in the Categories (thankfully the Category and Category Features behemoths can be drawn out with an API call). The problem was that the Category didn't have any FKs until I discovered the Category Features API calls. I then had to add FKs from Category to Category Features, which means I had to retest the entire section of Category, but after I populate Category Features.

The basic outline of any section of the program looks like this:



Python makes an API call and pushes the result into a staging table called json_insert. After insertion, the json is processed into relational tables.

If the entire program runs from beginning to end, I have something that looks like this, where each layer represents the flow in the above picture:



The testing issue is when something needs to be sandwiched between any of the two individual layers. Not only do I have to maintain and test referential integrity, I have to be sure that all layers successfully complete their tasks.

I now believe that automation is the holy grail of programming. Last night, I, uh, "wrote" over 10 KLOC using an automation script. If all goes as planned tonight, I expect to tack another 10 to 20 KLOC. Of course, these are all database tables.

Wow, thanks for pointing that out. I think you are right.

daveT, I don't know what you are doing but I looks amazing