| --- Log opened Mon Sep 02 00:00:12 2019 |
| 00:13 | | ErikMesoy [Bruker@Nightstar-r88323.bb.online.no] has quit [Ping timeout: 121 seconds] |
| 00:39 | | ErikMesoy [Bruker@Nightstar-gilb7q.bb.online.no] has joined #code |
| 01:15 | | Derakon[AFK] is now known as Derakon |
| 01:33 | < Degi> | Same |
| 01:47 | < Yossarian> | I've always had projects that are in an "unreasonable" section of my book or project folder. In the early to mid 2000s, my best friend at the time and I were considering making airburst shells like the prototype H&K OICW that was put in the US Army trials. But I couldn't afford the things I needed at the time to realize the technological feat. |
| 01:47 | < Yossarian> | 10 gauge shotgun shell at 3 1/2" is nearly 20mm |
| 01:48 | < Yossarian> | I have some crazy crazy projects in my notes. |
| 01:59 | | ErikMesoy1 [Bruker@Nightstar-gilb7q.bb.online.no] has joined #code |
| 02:00 | | ErikMesoy [Bruker@Nightstar-gilb7q.bb.online.no] has quit [Ping timeout: 121 seconds] |
| 02:03 | | ErikMesoy [Bruker@Nightstar-gilb7q.bb.online.no] has joined #code |
| 02:03 | | ErikMesoy1 [Bruker@Nightstar-gilb7q.bb.online.no] has quit [Ping timeout: 121 seconds] |
| 02:10 | < Pink> | Derakon, I discovered today that apparently the new standard particle shader has a basic distortion effect. |
| 02:20 | < Yossarian> | Although, now that I'm older I don't know... making weapons is a kinda iffy moral issue for me, maybe. |
| 02:21 | < Yossarian> | Particle shaders? I am a basic bitch compared to you, damn. I wish I could take this machine into my room and get online. |
| 02:21 | < Yossarian> | I get distracted when people come here at my mum's room and knock all the time, wanting to make small talk or borrow something. |
| 02:27 | <&Derakon> | Pink: noted, thanks. I'll keep that in mind when I get around to working on graphics again. |
| 02:27 | <&Derakon> | Right now I'm trying to get my AI ships to follow waypoints. |
| 02:31 | < Yossarian> | Hmm, should there be a #code hub to projects that aren't secret in nature? |
| 02:32 | < Yossarian> | AI ships and waypoints sounds like an awesome project. Was currently playing the alpha release of Star Sector. Decent so far in design but the ship types are bugging me. |
| 02:35 | < Yossarian> | Derakon: Ever play any of the X series games by German dev Egosoft? X2 The Threat or the X3 series (there are like 2 or 3 DLC expansions)? I like how they've balanced the ships in those games. |
| 02:35 | <&Derakon> | Different kinds of ships. :) |
| 02:35 | <&Derakon> | I'm doing naval combat. |
| 02:35 | < Yossarian> | DD, BB, CV |
| 02:35 | <&Derakon> | I briefly played X3 but found the learning curve to be a bit steep. |
| 02:35 | <&Derakon> | Yeah, like that. |
| 02:36 | < Yossarian> | X3 learning curve is steep but I think mouse steering for combat is the best option. |
| 02:37 | < Yossarian> | The UI could use improvement last time I checked. With Albion Prelude you can see stations or factories with missions from a distance with a tooltip |
| 02:38 | < Yossarian> | The hardest thing about X series or X3 is deciding what to do. Build a massive factory complex? Corner the market on a commodity? |
| 02:39 | < Yossarian> | I wish they'd go back to the codebase and implement a multiplayer, but endusers could do that with memory manipulation. Someone wrote a paper on doing this for Torchlight. |
| 02:39 | <&Derakon> | That's the other thing -- when I play space games I tend to want to be a single badass in a cool tricked-out ship, not the master of a merchant empire. |
| 02:40 | <&Derakon> | "Go back and implement multiplayer" is one probably the suggestion with the highest multiplier of (difficulty of implementation) and (frequency of suggestion). |
| 02:40 | <@Reiv> | yup |
| 02:40 | <@Reiv> | It sounds so simple! |
| 02:40 | <@Reiv> | It really isn't. |
| 02:40 | < Yossarian> | Exactly, that's my thing with StarSector (or is it Star Sector?) - the smallest sub-destroyer ships aren't very... like, viable? |
| 02:41 | < Yossarian> | The Kite model with the military hull, like you can increase speed and all that but there are two small missile mounts and a small universal in the middle. |
| 02:41 | <&Derakon> | My planned tactic for keeping small ships viable is to provide optional "complete this mission in a destroyer/cruiser/sub/etc." bonuses for some missions. |
| 02:42 | < Yossarian> | And yeah, implementing MP either with or without the codebase is hard, I know. |
| 02:42 | <@Reiv> | I mean, you don't need an ecosystem of balance anyway, you're a Hero Ship murdering entire flotillas |
| 02:43 | <&Derakon> | Yeah, mostly the issue with destroyers/cruisers in the game I'm basing this on is that they are so clearly completely obsoleted by battleships. |
| 02:43 | <&Derakon> | Which makes the DD/CA-exclusive items kind of disappointing to unlock. |
| 02:43 | <&Derakon> | Like, there's entire trees of cool ships that you're just never gonna use. |
| 02:43 | < Yossarian> | Last trist with X3 (with both the expanding DLCs) is I wanted this 600m/s heavy fighter with large cargo size, good weapon armament, and have a self-sustaining facility for pumping out combat drones |
| 02:43 | <@Reiv> | "Complete this mission in an X" is reasonable |
| 02:43 | <@Reiv> | So too, perhaps, missions where you need a minimum draught |
| 02:43 | <@Reiv> | Or! |
| 02:44 | <@Reiv> | Landing parties! |
| 02:44 | < Yossarian> | Minimum tonnage? |
| 02:44 | <@Reiv> | Your mission is to hare into a dock, offload Some Dudes, and get out and fend everything off while they do their secritive work. |
| 02:44 | <@Reiv> | That'd be fun to have Destroyers still around, for. |
| 02:44 | <&Derakon> | Why would DDs be better than BBs in that scenario? |
| 02:45 | <&Derakon> | I will note that WG2 had a mission chain that was "unlock some commandos from your sub without getting detected", "extract your commando team", and "fight the boss the commandos discovered". |
| 02:45 | < Yossarian> | DDs are faster generally speaking and require less crew; BB generally not high in knots and has a larger fuel requirement/logistics requirement along with crew |
| 02:45 | <&Derakon> | Crew, fuel, and logistics in general are Not A Thing in my game. |
| 02:46 | <&Derakon> | DDs are small, fast, and can mount torpedos; that about sums up their advantages vs. BBs. |
| 02:49 | <@Reiv> | BBs are not generally known for being able to pull in a harbour and casually stop on a dime to offload folks without any assistance. |
| 02:49 | < Pink> | Are you using a navmesh, or just trying to get them to move to a location? |
| 02:50 | <&Derakon> | Just a chain of vector3s. I haven't spent much time on it but it's a very basic concept. |
| 02:50 | <&Derakon> | I suspect that the only reason it's not working is because I screwed up the "figure out what direction to point in" code, but I'm taking a break now. |
| 02:51 | < Pink> | I mean, that's a perfectly reasonable way to do it as long as they don't have to avoid stuff |
| 02:51 | <&Derakon> | Right, the waypoints will route them around terrain, and they already have basic obstacle-avoidance otherwise. |
| 02:52 | <&Derakon> | If their obstacle-avoidance derails them enough they could get stuck behind some terrain I guess, but that should be fairly easily fixed with some raycasts/spherecasts to find somewhere that's reasonably open after which they can resume waypoint-following. |
| 02:52 | <&Derakon> | Or I might just not worry about it. I don't think most players will notice dumb AI so long as it's not repeatedly, obviously dumb. |
| 02:54 | < Yossarian> | It can be iteratively improved. |
| 02:54 | <@Reiv> | Not enough to worry about until it's obviously a problem, I reckon |
| 02:54 | <&Derakon> | Right. |
| 02:54 | < Yossarian> | You need to make a combat simulator sub-section for the combat to debug and test the AI |
| 02:55 | <@Reiv> | He's fine there |
| 02:56 | < Yossarian> | Star Sector has a simulation feature, I reckon that's how the guy has been debugging things from AI behavior to ship balances in terms of weapon damage, shield strength, hull strength |
| 02:56 | < Yossarian> | Derakon: If your game is like X3 but with naval ships, that'd be dope but I'm not sure what setting that'd have to take place in. |
| 02:57 | <&Derakon> | It is not X3 with naval ships. |
| 02:57 | <&Derakon> | It is Dynasty Warriors with naval ships. |
| 02:57 | <&Derakon> | There is no economy, literally no "sim" to it beyond stuff like "you can fire shells and they follow ballistic trajectories". |
| 02:57 | < Yossarian> | 2d or 3d? |
| 02:57 | <&Derakon> | 3D. |
| 02:58 | < Yossarian> | Well, it doesn't have to be a 4x style game to be interesting. I just heard the word "ships" and thought of X3 and Star Sector |
| 02:58 | <&Derakon> | I can see that. :) |
| 02:59 | < Yossarian> | You see how aiming systems work with ships from 1900-1945? With those trigonometric aiming stations, later ships use electronic signaling |
| 03:00 | <@Reiv> | He's not modeling that kind of thing, insomuch as ships do have to turn turrets and fire ballistically. |
| 03:01 | <&Derakon> | You pick a ship, lock onto it, then the guns automatically aim appropriately (with some randomized aim variance), fire when you pull the trigger, and automatically reload. |
| 03:01 | < Yossarian> | Oh, yeah. It's interesting how those old systems work though. Arguably, naval was ahead of the technological curve for a long time. |
| 03:01 | <&Derakon> | This is not "I have meticulously studied the mechanisms and created rules to simulate them with high fidelity", this is "I want to roll around in a cool custom warship and blow things up". |
| 03:02 | < Yossarian> | Like a trained sailor in the past 100 years probably needed to be more educated on average than others, because of the technologies involved in the new ships, gun turret technology, etc |
| 03:02 | < Yossarian> | and then naval aviation |
| 03:03 | < Yossarian> | That's fine, it's just an after-thought. I am a armchair military historian of sorts and I hadn't learned about the trigonometric aiming stations until fairly recently, last 10 years. |
| 03:03 | < Yossarian> | Saw a video and I was like "damn!" |
| 03:04 | < Yossarian> | I knew about mechancial computers for torpedo projectories and such |
| 03:05 | < Yossarian> | but aiming director for the modern naval ship with turrets was news to me |
| 03:07 | < Yossarian> | Derakon: are you using real destroyers and ships in your project? |
| 03:07 | <&Derakon> | Easier than inventing fake ones, yeah. |
| 03:09 | < Yossarian> | Imperial Japanese Navy's Fubuki class destroyers are good, IJN during WWII had aerial/AA firepower problems |
| 03:12 | <@Reiv> | He has plans to implement a whole bunch of them, yes. |
| 03:13 | <@Reiv> | Derakon: Anyhoo, a destroyer can be expected to pull up to a normal pier and actually unload people |
| 03:13 | < Yossarian> | Fletcher class for USN in WWII is probably the iconic destroyer for the USN |
| 03:13 | <@Reiv> | ... yes, he almost certainly knows that :p |
| 03:17 | < Yossarian> | You gotta include cruisers, not sure what the smallest ship size you'll have; that's my bugaboo for a game like Star Sector but X3 that isn't a problem. You can actually fly decent space fighters and get into some space dogfights |
| 03:17 | <&Derakon> | I'll be relying pretty heavily on pages like https://en.wikipedia.org/wiki/List_of_ship_classes_of_World_War_II |
| 03:22 | < Yossarian> | Trying to replicate the Kido Butai (IJN) in Star Sector; I think I'll do four carriers each with 3 bays |
| 03:23 | < Yossarian> | Spam the hell outta them with fighters and bombers/torpedos |
| 03:29 | < Yossarian> | But yeah, I was trying to get into naval affairs lately and I like both the space ships and the ocean ships. Oh, the air ships, too. |
| 03:31 | < Yossarian> | IL-2 1946 will play nice on linux but I don't have my joystick :( |
| 03:35 | < Yossarian> | Derakon: lemme know when you have project posting on github or some screenshots, your project sounds interesting man |
| 03:37 | <&Derakon> | I recently created a Twitter @byobattleship. Otherwise all of my stuff is posted on the SomethingAwful "making games megathread" and a project log here: https://forums.somethingawful.com/showthread.php?threadid=3896899 |
| 03:43 | < Yossarian> | Huh, you used to be a goon a a decade or two past? Interesting. I stuck to some parts of &totse in its hayday. |
| 04:11 | | Degi [Degi@Nightstar-srasoc.dyn.telefonica.de] has quit [Connection closed] |
| 05:03 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has joined #code |
| 05:03 | | mode/#code [+qo Vorntastic Vorntastic] by ChanServ |
| 05:35 | | Derakon is now known as Derakon[AFK] |
| 05:36 | < Yossarian> | I wish there was a site for people to list project logs of all types with tools for organization and for people to view them and get RSS feeds. Although eventually the person running the server and services would want to run ads or make money somehow. |
| 05:37 | <@Reiv> | I mean |
| 05:37 | <@Reiv> | There are, you know |
| 05:37 | <@Reiv> | blogs |
| 05:37 | <@Reiv> | And tumblrs |
| 05:37 | <@Reiv> | and such |
| 05:55 | < Yossarian> | I suppose |
| 05:55 | < Yossarian> | RSS feed for updates tho |
| 06:01 | <@Reiv> | Most of those have RSS in some form, too. |
| 06:08 | <&McMartin> | I went with a free Wordpress account in part because it does RSS "for free" |
| 06:10 | | Kindamoody[zZz] is now known as Kindamoody |
| 06:23 | <&[R]> | " tools for organization"? |
| 06:23 | <&[R]> | Like tags? |
| 07:20 | | celticminstrel [celticminst@Nightstar-6an2qt.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 08:04 | < Pink> | You'd have to be a git to offer some service like that. |
| 10:07 | | Degi [Degi@Nightstar-h52noh.dyn.telefonica.de] has joined #code |
| 13:25 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has quit [Connection closed] |
| 13:28 | < Yossarian> | git gud |
| 13:29 | < Yossarian> | That's weird, something in my one conky session seemingly held up network traffic |
| 13:34 | | Kindamoody is now known as Kindamoody|afk |
| 13:36 | | * TheWatcher readsup, notes he tends to be terrible about doing anything like project logs, in no small part because they end up falling into "there's no traffic to [logplace], why should I bother?", "Why should I spend time writing about this when I could be developing it?", or both. |
| 13:36 | <@TheWatcher> | Of course, the first of those is self-defeating, really, as there won't be traffic if there's no updates. But then the second one, egh. |
| 14:11 | < Yossarian> | I suppose that is a fair point. |
| 14:24 | | Degi [Degi@Nightstar-h52noh.dyn.telefonica.de] has quit [Connection reset by peer] |
| 16:14 | | celticminstrel [celticminst@Nightstar-6an2qt.dsl.bell.ca] has joined #code |
| 16:14 | | mode/#code [+o celticminstrel] by ChanServ |
| 16:20 | <&[R]> | TIL: don't mix async and procedural programming |
| 16:20 | <&[R]> | Do one or the other |
| 16:37 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 16:37 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 17:21 | <&[R]> | McMartin: https://linusakesson.net/scene/a-mind-is-born/ <-- of interest? |
| 18:30 | | Vorntastic [uid293981@Nightstar-6br85t.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 19:07 | <&jeroud> | Why do I find myself needing to write two different testing tools in Rust? |
| 19:12 | <&jeroud> | Also, why do people like mocks so much? |
| 19:17 | <&jeroud> | I don't really want to end up having to maintain a library, but I also don't want to build a bunch of general-purpose stuff into a random project. |
| 19:22 | <&McMartin> | [R]: Well, known to me already. Linus Akesson has done a considerable amount of superb work |
| 19:23 | <&[R]> | Fair enough |
| 19:24 | <&McMartin> | He's also the one that figured out why the "move the screen's origin on the monitor" trick corrupted RAM, precisely characterized it, and figured out how to work around it |
| 19:31 | <&jeroud> | Maybe I should add "why mocks are bad, here are some better alternatives" to my blog list. |
| 19:32 | <&McMartin> | I would like that article. Mocks are a major part of why I'm skeptical of TDD. |
| 19:32 | <~Vornicus> | story time |
| 19:32 | <~Vornicus> | worked on a system that needed to interface with a credit card system |
| 19:33 | <~Vornicus> | in particular I needed to wait for a proper approval from the bank. In the real world this took as much as a day: banks resolved these things fully at 3 am or so |
| 19:34 | <~Vornicus> | So this processor also had a sandbox, which you could throw test cards at and see how that goes |
| 19:34 | <~Vornicus> | ...which also had approvals run at 3 am or so. |
| 19:35 | <&jeroud> | I can type some of the highlights into IRC. The trombone part for Trumper's Lullaby is mostly rests. |
| 19:35 | <~Vornicus> | Which I mean, cool, it worked, but it does make testing the bit that handles that final approval a little hard... |
| 19:38 | <&jeroud> | I'll start with some terminology I tend to use, because everyone uses these words differently. |
| 19:38 | <&jeroud> | A test double is anything you use in place of something else in a test. |
| 19:39 | <~Vornicus> | I needed something fake that worked mostly like the real but didn't make me only try things once a day |
| 19:39 | <&jeroud> | The simplest kind of test double is a stub, which does basically nothing. It might be `None`, it might be a do-nothing implementation of an interface, etc. |
| 19:41 | <&jeroud> | Then there's a fake, which actually implements some of the behavior of the thing it's doubling for. This might be an in-memory dicta instead of a distributed key/value store or something. |
| 19:42 | <&jeroud> | A mock is somewhere between a stub and a fake, but it usually also allows you to make assertions about things that are done to it. |
| 19:44 | <&jeroud> | Because mocks are very popular (especially in TDD), there are lots of tools for throwing them together. |
| 19:45 | <&jeroud> | Because they're frequently used to make assertions about method calls and such, they're typically different in every test. |
| 19:48 | <&McMartin> | Oh ick |
| 19:48 | <&McMartin> | I've generally walked away from TDD before hitting that, but if I did I'd probably read it as OO cargo-cult |
| 19:49 | <&jeroud> | So a test might say `puppy = Mock(); puppy.expect.pet(area="head").returns("tailwag"); child.play_with(puppy); puppy.assert()` |
| 19:52 | <&McMartin> | As opposed to the "non-OO" assert(puppy.pet("head") == "tailwag")? |
| 19:52 | <&jeroud> | The point there is that you're testing child, not puppy. |
| 19:54 | <&jeroud> | The purpose of that test fragment is to ensure that `child.play_with(...)` calls `.pet("head")` when called with puppy. |
| 19:55 | <&jeroud> | The idea is that you can test the children without having to give them actual puppies. |
| 19:56 | <&jeroud> | (Maybe they're cloud-hosted puppies that cost a dollar each.) |
| 19:59 | <&jeroud> | A better way to do that is to define a FakePuppy class that has an actual `.pet()`.method on it and exhibits whatever subset of the relevant to the all the tests you're using it with. Maybe it also records where it was petted so you can assert that it happened, but that doesn't have to at methods-and-parameters level. |
| 20:03 | <&McMartin> | Yeah |
| 20:04 | <&McMartin> | I mean, that grates on me for other reasons, but that has more to do with my heretical position on the limited scope and utility of unit tests, and this example sounds like the kind I dislike~ |
| 20:05 | <&jeroud> | The way I see it, you should avoid test doubles wherever possible. |
| 20:07 | <&jeroud> | But sometimes they're actually necessary. For example, testing things that hit external services or when you need more control over things like timing and ordering than the real dependency gives you. |
| 20:07 | <&McMartin> | Yeah, and I tend to extend that to making end-to-end testing the primary focus |
| 20:08 | <&jeroud> | The best kind of test double is the verified fake. |
| 20:08 | <&McMartin> | 'verified'? |
| 20:09 | <&jeroud> | That's a fake that you test alongside the thing it's faking, asserting that the behavior of both is identical for the things the fake is used for. |
| 20:12 | <&McMartin> | Aha |
| 20:12 | <&jeroud> | That gives you the benefits of a fake (less flakiness than hitting something external, faster/cheaper test runs, etc.) while still retaining some confidence that your tests still have some kind of mapping to the real world. |
| 20:12 | <&jeroud> | Now I must drive, but I'd like to pick this up again when I get home. |
| 20:12 | <&McMartin> | And yeah, this is relevant for me because I'm currently setting up some systematic performance tests for an old server project to see how well it scales. |
| 20:13 | <&McMartin> | There are some "mock clients" in its testing framework right now, but they are fakes by your definition |
| 20:14 | <&McMartin> | I'm evolving them into "actual clients that we don't ship as part of the client software" so that we can hook them into convenient testing botnets while profiling instances of the server. |
| 20:14 | <&jeroud> | If they're lovingly handcrafted and used in multiple tests instead of being spat out of a magic metaprogramming machine, they're probably not mocks by my definition. |
| 20:15 | <&McMartin> | Yeah |
| 20:16 | <&McMartin> | There's "what the client actually does" and "what this server sees", and the former includes things like "interact with mobile phone hardware and be written in what are basically special purpose programming languages" |
| 20:16 | <&McMartin> | So, you know, maybe let's not do that for the server test code, let's instead build a program that interacts "honestly" with the server but gets the data it sends from a file, or, you know, the keyboard, because it's possible to make that make sense |
| 20:17 | <&McMartin> | That's not even a fake. |
| 20:17 | <&McMartin> | It's an alternate client at that point, one designed to be easier to script and mass-deploy. |
| 20:18 | <&McMartin> | And, sadly, given the team I'm delivering it to for future maintenance, one that needs to be written in Go |
| 20:19 | <&McMartin> | But I will acknowledge this is a better fit than the Objective-C that is the real client. |
| 20:36 | | Derakon[AFK] is now known as Derakon |
| 20:56 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 21:10 | | Pinkhair [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 21:10 | <&jeroud> | Yeah, your test machinery should generally be written in the same language as the thing it's testing. |
| 21:13 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 21:13 | <&McMartin> | Though it also raises a question about your taxonomy. |
| 21:13 | <&McMartin> | If you are testing a web application, is curl a "verified fake" or testing on an (unusual) production client? |
| 21:14 | <&jeroud> | I think I borrowed that taxonomy from an old Martin Fowler blog post. |
| 21:14 | <&McMartin> | (Assuming that the execution of provided JS is not crucial to correctness) |
| 21:16 | <&jeroud> | Curl is just a tool, not a test double. You're not passing it into the code being tested. |
| 21:18 | <&jeroud> | A client isn't really a test double either, but you could maybe consider it a harness or something. |
| 21:22 | <&McMartin> | If one thinks of batch-mode CLI applications as servers that take arguments and files and produce output and other files, that also sums up how most of Ophis's testing works |
| 21:22 | <&McMartin> | With shell being the 'harness' in that case. |
| 21:23 | <&jeroud> | Test doubles are basically dependency injection, if that helps clarify. |
| 21:24 | <&McMartin> | It does, though part of what it clarifies is "this is a discipline for developing the kind of software that, generally speaking, I don't develop" |
| 21:25 | | Kindamoody|afk is now known as Kindamoody |
| 21:25 | <&jeroud> | That's legitimate. |
| 21:26 | <&McMartin> | The closest thing to dependency injection that I end up doing is "this system has a plugin model with multiple libraries swappable in at this API boundary" |
| 21:26 | <&jeroud> | Do you call external services? |
| 21:27 | <&McMartin> | Yes, but not as usually conceived. |
| 21:27 | <&McMartin> | One of the things the client does is record from the microphone. |
| 21:28 | <&jeroud> | I sometimes make people's heads explode by explaining that in-memory sqlite is sometimes used as a test double for a more heavyweight database. |
| 21:29 | <&jeroud> | If you're testing the client, that's a thing you'd likely want to stub/fake. |
| 21:29 | <&McMartin> | The Audio APIs are very very much an "external service" with unpredictable and in some cases unknowable results. Apple has a nasty tendency to break invariants across hardware revisions, and has never adequately documented what aspects of the Audio API may be considered reliable. |
| 21:29 | <&McMartin> | And that's why I also say "not as usually conceived" |
| 21:29 | <&McMartin> | Because you don't have "a fake microphone" |
| 21:29 | <&McMartin> | Your library doesn't "read from a fake microphone", it consumes audio data and does not care where it comes from |
| 21:30 | <&McMartin> | And in quite a few subsystems, it doesn't even consume audio data, and those can be tested with textual material that's really easy to verify. |
| 21:31 | <&McMartin> | Our overall client application also talks to a server to get most of the data it needs to run, so testing non-UI client behavior is usually also a matter of potted inputs and scripted responses. |
| 21:31 | <&McMartin> | It helps that to a first approximation the server API is RESTful. |
| 21:32 | <&McMartin> | Faking *that* with an in-memory sqlite3 database not only isn't head-explody, that's how the client manages to limp along as best as possible when the server is not contactable because sqlite3 makes a dandy transactional cache and both iOS and Android ship with implementations of it in their stdlibs for exactly that purpose~ |
| 21:33 | <&McMartin> | This is a place where mobile development puts in some odder assumptions, though |
| 21:34 | <&McMartin> | Since the target application runs on a mobile device... |
| 21:34 | <&McMartin> | Almost all functionality testing of non-UI, non-hardware interactive stuff |
| 21:34 | <&McMartin> | If you can at all manage it |
| 21:34 | <&McMartin> | You do not want to test it on the final deployment targets! |
| 21:34 | <&McMartin> | So the idea that your functional core should be a linkable library that's independently testable on any platform is baked in so deep it's the kind of thing one forgets to state. |
| 21:35 | <&McMartin> | Dependency injection tactics and the like are how stuff gets knitted together at the end, maybe, and honestly probably not because of the model of what a mobile application even is. |
| 21:36 | <&McMartin> | to wit: something that is not precisely a statically linked binary but which is designed to approximate one as closely as possible |
| 21:36 | <&McMartin> | and if they can make it be "a preloaded image of a virtual memory space" they'd rather go with that when they can. |
| 21:40 | <&jeroud> | Does that functional core involve things like UI interactions? |
| 21:41 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has joined #code |
| 21:41 | | mode/#code [+o Reiv] by ChanServ |
| 22:00 | | Kindamoody is now known as Kindamoody[zZz] |
| 22:19 | < Yossarian> | I think I'm slowly making myself the weirdo of the channel, not sure how to feel about that. |
| 22:20 | <@Reiv> | Focus on the programming and ask for help as needed? |
| 22:23 | <&McMartin> | I'm in no position to snark on the wackiness of anyone's projects. |
| 22:24 | <&jeroud> | Yossarian: You and I don't overlap much, so I have no real comments. |
| 22:26 | <&jeroud> | But if you're not upsetting anyone more than necessary, there's no problem. |
| 22:26 | <&jeroud> | If you want to talk about weirdos, TheWatcher writes *readable* *perl*. |
| 22:34 | <@TheWatcher> | https://i.imgur.com/kpTtT.gif |
| 22:47 | <@Reiv> | :D |
| --- Log closed Tue Sep 03 00:00:13 2019 |