I’m really finding the resharper code cleanup/fix functionality for C# to be helpful. I’m reading through my copy of C# 9.0 in a Nutshell and finding features that are useful, but it is much faster to write something and have a ‘cleaner’ alternative proposed and presented by the tools.
Slowly the tools I need to build the tooling I want is coming together and I’m feeling better about the classes I write here. My C# code has been serviceable in the past but I’m now feeling more like I’m making best use of the available language features.
I’ve given in on PInvoke 🙂 and I’m using that to get to any native API calls I need that aren’t exposed in the core C# libraries. Currently mostly volume and file information stuff. Also looking at (for tangentially related reasons) display layout APIs. Keeping me busy when I’m not polishing work related network cryptography specs.
My friend Malcolm suggested using VR chat.
He mentioned spatial.io and VR Chat as options. I registered with both of these as KyleWilson.
So far it looks as if spatial.io does not support any of the PC based 6 DOF room scale devices and since my primary VR system is an HTC Vive this limits my options on that front.
VR Chat looks more promising and I’ll install the windows application tomorrow to see how it looks (it appears to be a steam app).
Just queued it for download on jabberwock (the VR system in the basement). Looks like it already installed…more tomorrow.
It has been a wild ride this last year.
I’ve gone from someone who pays attention to cryptography and cyber-security to developing network cybersecurity architecture.
I’m always up for a challenge and this one has been a big one. So far things have gone well though.
It certainly has kept me busy as the lack of blog posts or significant GitHub commits will show.
I’m not far more deeply aware of the inner details of:
- TLS 1.2 and TLS 1.3
- TLS pre-shared key algorithms
- TLS 1.3 session resumption
- AES implementation choices.
- Cryptographic random number generation and primary entripy source selection (this last a work in progress)
- Elliptic curve cipher suites for TLS
- SSH/SFTP protocol details and security implications in there.
- Modern password hashing algorithms (BCrypt, SCrypt and PBKDF2)
- Lots and lots of trade-offs between security, performance, implementation time and cost.
- X.509 certificate details and ways of creating, managing and distributing certificates. PKI both big and small.
- Some fun with trusted platform modules.
A wild ride indeed and not over yet. If this all keeps coming together though it should lead to a very satisfying conclusion.
This has certainly added a lot of tools to my toolbox. I’m now much better equipped to deal with secure networking issues and implementation. Once thing with network cyber-security work is that there’s always one more detail that needs to be addressed.
I am hoping to free up some time on the home front to get back to some of my home VR software projects this fall. Still dithering on whether to buy a resharper license. I’ll probably pick up ‘cluster’ again and try to move that to a more complete state. Might also play with some smaller VR toy programs…tempted to put together a very small gravitational system simulator in room scale. We’ll see how all that goes. I really need to get back in touch with Malcolm and Sam and see how they’re doing.
From Bruce Schneier…
Looks like there’s a new collision attack that reduces the work another notch. It was clear before that SHA-1 is a no longer viable…this just makes it clearer.
I watched a few conference sessions talking about software process yesterday evening.
There was one discussion of agile that I really liked. I’ve seen quite a few parts of agile processes that I think add value but I’m not convinced that the overall processes map well to the sorts of large, embedded software projects that I’ve generally been involved with.
Another session made some very good points related to dealing with technical debt. The presenter had some very interesting thoughts on using source code control system information to direct refactoring efforts. It makes sense that modules with significant complexity and lots of ‘touches’ are good candidates for clean-up. He also made the excellent point that attacking issue counts will focus everyone’s attention on the small, low risk, low reward items that can run down the count quickly. Dealing with a thousand minor naming issues will do little to improve tangible code quality. Addressing a single, large snarl of complex interactions may result in huge improvements. I long ago realized that uncritical use of metrics can derail a team faster than anything else.
There was also a short functional programming session that seemed decent. It still didn’t address my biggest pain points with functional though.
He made a decent case for the merits and limitations of functional approaches. I tend to buy them for ‘business logic’ type work.
The place I run into trouble with functional (and to a less extent the JVM languages in general) relates to numerics work.
I’ve spent a chunk of time processing images and signals. I still don’t see how one can reasonably implement something like noise reduction or sharpening of a reasonable size image (say 5000 x 5000 RGB pixels) in a functional language. Immutable arrays would seem to leave the developer with a lose/lose/lose set of choices.
- Direct approach – Process each pixel in series and create a new image array with the updated pixel. Repeat this 5000×5000 time, copying the array at each step.
This obviously fails even in a garbage collected environment as the process of copying megabytes of data for each pixel update will kill you. It does mean that access to adjacent pixels should be reasonably fast as reads will be no different than in a procedural environment.
- Partitioned Tree approach – Build your large array as a tree structure under the covers with (say) 32 elements per leaf node. This was the approach suggested by the presenter in the talk.
This seems to be the worst of all possible worlds. Read access to each pixel requires traversing several levels of pointer indirection. If 32 pixels in a row are updated then we generate 31 ‘dead’ copies of the segment along the way. Locality of reference becomes a mess as adjacent items in the ‘array’ may be anywhere in memory.
- Process and Reassemble approach – Run through the entire source image and generate a change list to be applied. Once you’ve finished with the image, generate a new array with all of the specified changes in place.
This will potentially generate a list of tens of millions of update entries in memory. I’m also not sure how one implements the ‘create a new array based on this array with these updates’ in an immutable environment. I guess this is the bottom line of all of the functional coding I’ve run across…the functional environment seems to always assume that there is procedural ‘magic’ to make the ends meet. I suspect that the answer would involve writing the image processing primitives in a ‘real’ language and then exposing them as unitary operations on the functional side. This rather strongly suggests that functional languages will always be a specialty item and not the ‘main course’.
I’ve been spending some time looking into password hashing best practices over the last week.
I’ve know about the BCrypt algorithm for a long time as the old BSD standard ‘high effort’ hashing algorithm designed to make brute forcing hashes difficult.
I’ve found that there is a new effort called SCrypt intended to generate a modern equivalent for dedicated password hashing as well as a ‘password expansion’ algorithm that appears to be in wide used called PBKFD2.
The PBKDF2 algorithm applies an HMAC using the key input to inject the salt and then to chain iterations of the process. It takes a user selected number of iterations that allows the work-load to generate the hash to be tuned to the scope of expected attacks (and to the performance of the target hardware). This allows modern high performance algorithms such as SHA-256 to be applied in a manner that makes the total calculation of the final salted hash resource intensive enough to reduce the likelihood of a successful brute force attack.
I’m quite familiar with much of the content of C++ 2011 as it represented a welcome and long desired step up in C++ language capability.
I’m less clear on the changes that live in the 2014 and 2017 incremental updates (smaller and more tightly focused) and the upcoming work that will feed into the next release.
Getting on top of this is becoming more important as I’m back in the C++ world and while almost everything should support C++ 11, the later iterations may be missing or fragmentary.
I’m spending a little time this afternoon looking through resources on this front, starting with the C++ 2011, 2014 and 2017 pages on wikipedia.
I have pulled the draft PDF file for 2011, 2014 and 2017 and grabbed the github source for the standard(s). These are quite useful, but seriously deep waters if only the changes are of specific interest. Interesting pointers on where to buy the official docs here with the 2017 version from ANSI at just over $100.00. The current working draft appears to be on github here. I may take a shot at building that into a readable PDF at some point…
I am also rather interested to see what is in boost these days. Back in the visual studio 2010 era, the TR1 content that eventually fed into C++ 11 was one of the bigger draws…now that is part of the core tools in general so I’m expecting a new range on interesting bits. The seem to have a github repo here.
And here is the C++ 20 page. Interesting that 20 looks to be much more like 11 than 14 and 17 (which were small tweaks).
On the flight to San Diego I did some Unity refresher reading and some thinking about game ideas that might be worth playing with.
I was looking for references to ScriptableObjects in the books I’ve got and didn’t find them. Guessing the focus there is too new to show up. I’ll post a bit on the ideas front over on PandaMallet in a bit.
It has been a slow summer on the home technical front and I really want to get that stuff rolling again as we move into fall. Plenty of interesting stuff to do, just need to find the time and decide to focus.
I had a short conversation yesterday about securing UDP data. When I dug around little it became clear that there is an existing, RFC documented protocol for handling that. I haven’t yet read the specification (though I likely will as it is an interesting technology).
There is a wikipedia description here and the primary RFC is here.
Being able to secure unsequenced and unreliable datagram traffic using a design that is reasonably well vetted seems extremely useful. There are places where UDP is uniquely useful and security is becoming a much larger issue in the market today.
Interesting looking sample code here.
I’ve done some development in an agile/scrum environment. There are a number of things it brings to the table that I see improving code quality in some ways and providing a more stable delivery schedule.
With all that being said, I don’t believe it is a silver bullet and I become a bit annoyed when I read books and articles that present it that way. I’ve been doing some refresher reading lately as we’re working with customers who run agile teams here and I’d like to help our team adopt useful bits of agile without harming our overall effectiveness. This is particularly challenging in a regulated environment like the medical device development we do here. It is also challenging when we’re doing contract development engineering and customers expect to have a contract that covers the work we’ll do before they start paying.
I’ve been running some sort of daily stand-up long before I heard of agile or scrum. If anything, scrum environments seem to make stand-up longer and more formal. In lead roles before I hit scrum environments, my stand-up usually involved going to wherever the bulk of the team was located (if I wasn’t already there…jobs varied) and having a short discussion with members of the team about how things were going.
One aspect of stand-up that I don’t endorse is the ‘blockers’ question that usually seems to be a rote part of the process. In a team of under ten people, there should never be blocking issues that last for more than a very short time. If you know who can help you then just ask (by email if they’re not immediately present). If you don’t know who to ask then either ask your lead or ask someone else and follow it up from there. If someone consistently fails to help those who need assistance then the team needs to stage an intervention and make it clear that we work as a team.
Blocking issues should never persist for long enough to make it to stand-up.
I also tend to use stand-up as a platform to address team wide issues and support issues that people encounter. Another side-effect of the ‘keep it short’ philosophy of scrum stand-ups are ‘information free’ comments. Telling the team that you’ve closed issues/stories ‘1123 and 1127’ and are starting work on ‘1134’ doesn’t really help to share information with the team. It may help the leadership track progress, but they have plenty of tools to do that already if you’re using any sort of software to manage work-flow.
I think this is enough for one day…I’ll add comments in another page in the near future…
Prev | Next >