level

Cached mirror, since I'm getting a gateway timeout: https://web.archive.org/web/20220927155115/https://connortum...

I recently left a boutique agency of 5 years and I can definitely resonate with this one. Our agency aimed to catch big fish, and we did, but since they are hard to land we'd pick up small jobs in the meantime, just like the project that you're describing here. In my perspective, this isn't someone deliberately ripping you off. I imagine they intended to ship at the cost they quoted, but the team didn't adjust their working style to match your price point.

All the variations of the logo and design mocks are clearly overkill for a $15k project. The design team had time to fill and wanted to provide lots of options for you to pick from, as they typically would on a larger project. Those variations are an expectation for $100k clients, and you got the $100k customer treatment, but unfortunately not at a discount.

The reality is, small jobs like this are effectively make-work projects for an agency. They typically don't pay enough to be an effective use of time for the agency, but are a way to stay in the black between higher value projects. Small customers become "nuisance" customers as soon as a something better is landed. The team members being swapped out as they are needed elsewhere and newly joining team members then need to re-contextualize and regain momentum, all on your dime.

Your takeaway is correct, don't be a small fish for an agency. If they're busy they won't take your work, and if do show interest, they are desperate for work.

Along a similar vein, Sophie Alpert did a talk[1] at React Conf this year on building your own React custom renderer by using implementing the interfaces that React exposes. Sophie explains how you could use React as a declarative API for pretty much any platform if you wanted, similar to how react-native works.

[1] https://www.youtube.com/watch?v=CGpMlWVcHok

I built a server a few years ago, and I determined it was more cost effective for a drive to fail than to use HGST. It would be more inconvenient, but having a drive fail on a home server with only 6 drives didn't seem very likely anyway.

The article covers the use-case of making small modifications to the build. react-app-rewired[1] and customize-cra[2] give you access to tweak the webpack build indirectly. While babel-macros[3] in CRA 2.X give you access to the babel transpilation step without having to eject. While it's not exactly what you're referring to, it does get you a little bit closer to the build.

[1] https://github.com/timarney/react-app-rewired/

[2] https://github.com/arackaf/customize-cra

[3] https://babeljs.io/blog/2017/09/11/zero-config-with-babel-ma...

Have you explored the mithril.js [1] project? It seems to have reasonably similar goals, although the templating is pretty different from how you implemented it. Mithril doesn't have a concept of state, which also sets it apart from your project, but it seems to handle re-rendering just fine without it.

[1] https://mithril.js.org/

The problem is that it's not idiot-proof. If someone doesn't understand why the algorithm is important, they might choose none. It's easy to say "they shouldn't be using JWTs if they don't know how to use them", but everyone starts somewhere, and everyone puts stupid bugs into production.

JWT is safe, as long as it's setup correctly, but safe-by-default is a better option.

That being said, I'm not going to swap out my JWTs with PASTs. I know what algorithm I'm using, why I'm using it, it is safe, and I'm verifying them properly.

Rather than maintaining a list of HSTS websites which isn't cross-browser, why is there not an optional HSTS flag attached to the DNS response? I don't know anything about DNS requests, so changing the protocol in a backwards compatible way might be impossible, but that seems like a much better way to maintain that information than with a separate list.

Probably, but contract issues could lead to a hefty legal bill as well.

The marketing site does it better [1].

[1] https://teletype.atom.io/

I thought the post seemed to indicate it was production ready, but then again, they said the same for Coral. The forum post for this announcement indicates that they have no planned 9.10 updates, so I would think that 11.0 is meant to be the next production ready update. The GUI is a beta release, but that seems to be the only non-complete portion, and I would hardly let that hold me back from upgrading.

That being said, I'm holding onto 9.10 for a few months, to see how this release turns out. Moving my jails to docker is a welcome change, but not something I want to jump on immediately.

Stephen avenue in Calgary has some structures that were built to prevent wind gusts between buildings[1]. The street has a lot of foot traffic and that area became windy after the two skyscrapers on either side were constructed. Not sure about the cost to the city, but they're interesting to look at and they seem to achieve their goal.

[1] https://www.google.ca/maps/@51.0456499,-114.0704853,3a,75y,7...

Atom tends to be my go-to, but being built on Electron is what hurts it the most, in my opinion. I don't reboot my work machine often, only for updates, which means that having 2 or 3 projects (in 2 or 3 windows) can eat a lot of memory if it has been open for a while.

It's frustrating having to restart my editor because the Electron window gets stale and needs to be closed.

The entire HTTP request, including the destination, is bundled into the TOR packet, AFAIK. Only the exit node on the tor network can know where the destination is. But even then, when using HTTPS, the exit node only knows the host of the HTTP request, not the entire URL.

I can't believe I missed that, for me that's a killer feature. I can't wait to try this out.

I imagine an integration with Appetize[1] would be very useful, as well as an opening for a possible revenue stream. Being able to build an RN app and then run it right in the browser removes another barrier for sharing RN code easily.

[1] https://appetize.io/

All of your job postings end with (m/f), what do you mean by that?

Additionally, I've looked at positions in Germany in the past, but I have no fluency in the language. Would that prevent me from being an appropriate candidate?

This is pretty much how I found a couple exposed Stripe API keys. You just need to look through code of people who use the example implementation, and then dig in the history/config a bit. If you send stripe a key or two, they'll give you a free shirt.

https://adamlaycock.ca/blog/2016/05/23/Stop-Posting-Keys.htm...

To be fair, 4.3.2 the current LTS version, but would ideally be migrated prior to April.

https://github.com/nodejs/LTS

Modules in RC5 mostly fixed that. You still define all the dependencies and directives, but they're all packaged into a module file, and then you can use use any components by dropping them into your template. Getting something like an Angular 2 snippet tool will also speed you up a bit.[1]

[1] https://atom.io/packages/angular-2-typescript-snippets

I looked into this a while back, but bailed on the idea because it violates the TOS of a bunch of APIs. For example, the Google API terms specifically notes that you cannot aggregate their content[1]. There were a number of issues with other API terms as well, such as completely disallowing any caching or storing of data, I can't recall which ones, but if you read the terms, you'll find they're quite restrictive.

Ultimately I decided not to pursue the idea since there's no real opportunity for growth, since all your content comes from your competitors, who can easily shut you down.

[1] https://developers.google.com/maps/terms, section 10.5 (d).

But also recognize when you'll need it, before you need it. I'm working on a React Native application without Flux, and it's turned into a massive roadblock because there's no concept of unidirectional data flow. Passing state up, down, and trying to sync it between components has become a mess and has lead to very tightly coupled components.

Truthfully, my knowledge is second hand. I haven't spent a ton of time with it, my coworker is the one who had issues learning it. I've spent a little time with it, and haven't had the same issues he ran into.

I think the issue comes from the learning curve between jQuery and Mithril. Coming to Mithril from React I'd imagine would be relatively easy, where coming to it from JS spaghetti would be rough due to the lack of adoption and step-by-step tutorials that exist compared to React.

The site appears to be getting hit pretty hard, here's Google's cached page: https://webcache.googleusercontent.com/search?q=cache:Hi1cki...

We're currently using Mithril and one of the biggest issues was getting started in it. It's adoption is lacking, making finding people who've had similar issues difficult. Solving every problem yourself is much harder than finding an existing answer on SO.

That said, we still use it, but we're considering moving to React in the future, mostly since its learning curve is a lot less steep and we would be able to iterate faster.

I'm not an encryption guy, so I'm probably totally off base, but how does this work in terms of decryption?

When you 'friend' someone, are you sharing your decryption key with that person? That seems very vulnerable to mass data collection when you start emailing it around to friends. Does each friend get a different key that you can disable if you believe they've been mismanaging your key?

Many of our current encryption algorithms can be broken by sufficiently powerful quantum computers [1]. We're still a while off from usable quantum computers, but they are coming, eventually.

[1] https://en.wikipedia.org/wiki/Post-quantum_cryptography

Thanks for the reply! I'll take a look at it soon, I'll definitely grab these again. I think the version I used was from July, so it's definitely outdated.

I got the M1530 back in 2008. Not my primary machine, but it's definitely reliable.

I'm using these for my smart mirror project, and tied them by index to the Yahoo Weather API.[1][2] There isn't a perfect one-to-one relationship between the API codes and the icons, but it's pretty close.

My one complaint about the icons is that they flow outside of the boundaries of what you'd expect them to be contained in, which can lead to some accidental overlap if you aren't careful with your margins.

[1] https://github.com/alaycock/SmartMirror/blob/master/public/j...

[2] https://developer.yahoo.com/weather/documentation.html#codes