I've been working on something that might be worth giving a try! [1]
It's built more for specifically for software architecture rather than general whiteboarding, but we just recently added custom icon uploads so you could add whatever icons you want if you're more interested in hardware. The 'logical component' operates in two modes, one which is just a group, and one where it acts like a sub-board that scales its contents to fit the box.
Super cool! I'm excited to explore it as an excalidraw alternative for a lot of the diagrams I make.
Some initial notes:
- On the very first initial load, ~~there's no default tool selected~~ it selects the 'hand' tool in the bottom left, which hides the cursor. It seems to select the pointer tool after a refresh. I'm able to replicate in an incognito browser or by clearing site data. After scanning your documents, it appears its touchscreen related. My guess is that it got confused because I'm using one of the ASUS Duo laptops.
- I personally think it makes more sense to start docs on "What is Context" (on the documentation drawer), but that's a matter of opinion. The sandwich icon isn't as obvious as I'd like though, and it'd be nice to have a link to the next page at the bottom of every article.
- my initial thought from the sequence diagrams panel was that I could type to generate an initial image, then drag that into my canvas for position changes.
- this actually makes me think about mermaid's rendering engine, and how hard it would be to support moving and "pinning" an element, such that further diagram changes need to work around the pinned elements.
My understanding of it is that HN/YCombinator would also have to be targeting EU customers directly, such as by offering the service in EU languages (english probably wouldn't count) or offering prices in EU currencies.
Not trying to argue, I don't know the GDPR details, maybe it's written that way, but that wouldn't matter. EU law does not apply to US corporations or citizens unless they are in the EU or are concerned about getting assets taken that are in the EU.
EU laws can totally apply to US corporations or citizens. It may not be enforceable however. (The US has a good history of applying their laws on non-US citizens, just check who has been sued over copyright violations)
Hard to say it applies of it's not enforceable. That's re-defining apply to meaninglessness. It's also a window into the argument that there's no attempt to make "global gov" via subversion of national sovereignty.
If the law applies that means a corporation could get into hot water if customers or vendors in the EU don't want or can't trade with them anymore.
The law applies to them in the sense that if they don't follow it, they face negative repercussions. It is not enforceable by the EU directly since they aren't in their jurisdiction.
Application and Enforcement of Law are, atleast IMO, separate things. It's an implication relationship of Enforcement->Application. Application alone does not mean it is enforced but enforcement means it's applied.
Difference being that if the law applies then the EU might want to enforce but lacks the teeth to. They would if they could.
The problem usually starts to occur when the company that starts subverting your rights is too monopolistic on a market with either a high barrier to entry or a strong networking effect (CPU/GPU vendors and social networks).
In this case choosing another vendor may not be easy (find a GPU that isn't AMD/NVidia/Matrox and that works with most games or find a social network that allows the same reach as facebook or find a video sharing site with the same ad revenue and reach as youtube)
I'm with you there. Antitrust law has been applied effectively (although in the FB case, I find it hard to come up with a technical argument as to why, it's just MySpace 2.0 and we will laugh about it years from now). I tend to jump into these conversations because it's often related to a push for more law.
On my first pass of the title on the front page I figured this was going to be a Legend of Zelda game... This article is not as fun as LoZ, not even in the slightest.
Their main product is an Enterprise Service Bus, a piece of technology that is supposed to help make it easy for software developers to integrate with multiple disparate third party solutions (and potentially internal solutions). So you can get a "Connector" for SAP, and another for Salesforce and consolidate, transfer or do practically whatever with the data in both systems, without having a bunch of developers working on an in-house solution to consume the requisite APIs.
My one criticism of them would be they focus very heavily on cloud, and their on-premises offering is woefully anaemic, lacking fundamental functionality, such as messaging.
Catchy, but no. Mule ESB is more like a framework for declaratively creating (and executing these) flows that run through a series of components that react to events, in a sort of universal design pattern; these flows then execute in in a runtime that uses SEDA [1]. They give you some built-in components that help in creating APIs, and this design is a good fit for APIs and data munging, but it can be used as "just" a runtime for event-driven code. For a clearer example, see my other post here [2]. Their other products include an API proxy and a client-facing API gateway.
> Mule ESB is more like a framework for declaratively creating (and executing these) flows that run through a series of components that react to events, in a sort of universal design pattern
I hope I don't sound too snarky here, but from bird's-eye view, this description sounds like business-speak for:
"It could have been normal programming with external services, with all perils and pitfalls. But in addition to the common pitfalls, you get a badly designed domain-specific language (DSL), using XML syntax to make it even harder to understand, with the promise that you can hand it over to non-programmers, except that you need programmers to extend the DSL with custom components anyway, to make it actually work for you."
Hoping this superficial judgement is wrong: How does the real product deviate from that snarky description?
Apart from the non-programmers bit, you're not wrong.
I've been using the open source version on a project between 2013 and 2015 and it was exactly as you described: it essentially was a very convoluted and un-debuggable way of attacking a class of trivial problems, on which it failed miserably.
Basic functionality (watch a directory for incoming files, apply some processing, move the files to a second directory) would fail without any useful error message. You could "program" it by writing XML files with an Eclipse plugin, but anything non-trivial would involve hundreds of lines of "magic" XML.
Worked with the on-premise version, and I'd avoid it like the plague. Badly designed mix of XML and old-school Java, if it wasn't for political reasons we would have kicked it out.
XML/Java is very much it's ancestry. Back in the day, it competed eye-to-eye with ServiceMix and Camel. Both of those have remained firm Apache products. Mule ESB was heavily commercialised, for better or worse.
Don't worry about the code looking dirty, embryonic code always does. If it's a big enough tool it may warrant setting up a GitHub Pages site for it, just to make it a bit easier to find when somebody is suffering from the same problems you were.
In terms of new features, once you've put the repo on GitHub (or wherever) other people will likely suggest features as issues or modify the program themselves (and hopefully open a PR).
> And yet, by fixing any one of those, you'll probably break something else.
That's an empirical claim and I doubt it's true. Sure, sometimes you'll break something else, but 50% of the time plus? I'm gonna need to see some evidence.
I would start by kicking off the process of codifying your knowledge. I've used confluence for this, and it's a real art to sit down and work out how to structure your information, the level of detail required, and what should be documented in the first place. I've found that the people I've worked with the went from a technical to managerial role were mostly relied on for that vast technical and organisational knowledge that they had built up over the years.
I'm not sure if you're managing a project, product or divisional team structure, but I would say that no matter what level you're attempting to manage, set some sort of vision for your team to align themselves with. This can cover things such as technical aspirations, or organisational strategic goals.
Trust your team. It doesn't sound like there is any mistrust in your team, but I understand the difficulty in getting over that initial knowledge hump when introducing people to a new domain, especially as an "expert" in the area. Documenting knowledge in clear and concise ways, and making different members of your team experts in certain areas of your knowledge will help them to become more self-sufficient in their quest for knowledge and answers. Consider this an investment.
As a general piece of advice, not aimed at any particular part of your post, you were in the same position as your team members are now not long ago, think about the pain points you had and try to learn from them.
That works under the assumption that humans are purely rational beings, which we are not. Though I don't necessarily think the design chosen was a great choice based on other comments here. Maybe something a bit more generic, yet still colourful (like the candies in games like candy crush) would have been a better choice.
Maybe, and if they were selling something for display, like figurines, or even a quasi-collectible I would be right there with you. I know people who like that kind of thing, and they would like a funky box too. This is JUST candy though, it's just people buying something they want to eat. It's a different mindset, and I think, less likely to be engaged by the aesthetics of the packaging (as in the box). They're interested in the packaging of the actual candy, and the candy itself.
reply