The points in that doc are ordered in a clockwise direction, so I reversed the order and added them to an SDO_ORDINATE_ARRAY which generates the following.
It’s a nice leaf but not quite Canadian enough.
I was unable to find a complete mapping of a leaf closer to the Canadian flag, so I found several examples that were all similar but incomplete, and did my best to guess at the missing data.
I started at the top point and worked my way counter-clockwise around the leaf points to the bottom left stem point.
Since I centered it on the 0 x axis I simply removed the negative from the x ordinates, reversed the order of the coordinates and added them to the SDO_ORDINATE_ARRAY. Notice the start and end points are the same to close the polygon.
After checking that the object is valid using .st_isvalid() I generated this leaf.
I’ve been writing software for many years. And I’ve realized lately that the more I engaged with (wrote in, integrated with, etc.) open source technologies, the better the code I write gets. Which got me wondering: correlation or causation?
Reading code makes you better
I learned early on in my programming career that the more code I read, the better my code became. I learned that when I had to maintain other people’s code, simple and clean almost always beat fancy/complex code – even if there were comments. On the other hand, when I took enough time to understand the complex code, I usually learned new tricks. Either way, I improved.
This led me to push for code reviews in shops where we weren’t doing them. And when there ‘wasn’t enough time’ to do code reviews officially, I would browse the repositories and read the code on my own. Of course, back then I was limited to the company source from small teams.
Going beyond the syntax
While you inevitable had to wrestle with the syntax of any programming language, that’s the most trivial aspect of learning how to fully leverage that language. The syntax of a language tends to be pretty static, and if you get it wrong your compiler will complain. Deeper lessons involve what kind of problems a language is best suite to solve (“right tool for the right job”), and how best to write code in that language so it is efficient and maintainable.
There are many ways to pick up a new language; courses, tutorials, mentors, books and more. I often use combinations of these options when I learn a new language. One thing I noticed is they are frequently very similar when it comes to the non-syntax elements. Obviously following recommended practices.
When you read real deployed code from other people you get something more. You learn patterns and practices beyond what’s in normal structured learning. The “correct” way to do something in a language is not always what works best. You see the edge cases, one offs and unexpected integrations. You will see solutions to these issues, both good and bad, but if you really think about it, this is where “recommended practices” are born. Today’s pattern is tomorrows anti-pattern.
You may have strong feelings about things such as ‘always comment’, ‘commas go at the end’, ‘indent x spaces’ and of course you’re ‘right.’ I’ve had very strong feelings about those and other aspects of coding.
As I read other peoples code sometimes I would get angry that ‘they were doing it wrong.’ As I read more, I started to understand that there were situations common in other peoples code that I had not encountered in mine and my way could be unnecessarily more difficult. I not only changed some of my opinions, but I am learning to be more flexible.
Open Source is Everywhere
As the open source movement grew, so did the amount of code available to read and learn from. With sites like Gitlab, GitHub and BitBucket we can pull down fully functioning applications to not only read, but tinker with. I rarely encounter something I want to learn that doesn’t have at least some open source code available to play with.
I remember starting out with a new language and stressing over simple things such as directory structure and naming conventions. Now I go look at a few different open source projects and I can start to piece together common approaches. I rarely stress over these types of things any more.
Nowadays there is so much code available, both good and bad. When you’re learning, you don’t really know which is which. Just keep reading and you’ll learn to tell the difference. Reading ‘bad’ code helps you understand why it’s ‘bad.’ The key is not being afraid to try whatever you think looks correct, admit when you get something wrong, fix it and move on.
Bad Code is Bad, or is it?
Some would say “there is more ‘bad code’ out there than ‘good code.'” Here’s a sub-reddit dedicated to bad code.
I’ve written plenty of good and bad code over the years. When I look at my older code I often wonder how I could have written such crap. This really means I’m still learning. If I can look at my old code and think it looks great, it means I’m not growing.
So how can we learn from bad code?
The more bad code you read the better you will be at spotting it.
As you’re learning and searching for examples, you will find and use a lot of code that doesn’t quite work. Remember, just because it doesn’t work for your situation, that doesn’t make it bad. Learning how to make it work makes you better.
How do you know it’s bad?
People love to criticize. Read the comments, if you see a lot of ‘WTFs‘ you may be looking at bad code, figure out why it’s bad. Please don’t be one of those people who just leave a “this code sucks” comment. Don’t assume you know all of the requirements for the bad code, there may be a valid reason for the way it’s written. If you can see why it’s bad try to leave a constructive comment. Or…
Don’t leave it bad.
Put in a pull request that makes the code better. Fix the syntax, use a better method, add comments or fix the indentation; these are all great ways to help. Add a good explanation for why you are recommending a change.
I learn more when I help someone else learn than I do on my own. If I think I understand a new topic I go looking for someone to explain it to, this makes it stick in my head and I quickly find out if I’m writing bad code.
Remember open source works best when there is participation. Code changes are welcome in most projects, but there are lots of ways to contribute.
Test open source code (you know you want to!) and file bug reports; help complete the documentation set; write tutorials and how-to examples; participate in the conversations – or simply help spread the word. Everything makes a difference, and the more fingers in the pie, the better!
Here are a few links to help get you started. Some I’ve worked with, some I haven’t yet had time to dive into. If you find something useful – or something that needs correction in this post, please don’t hesitate to share it.
Anyone who knows me know that if I form a strong opinion about something, it’s because I believe I have examined all the available facts. Of course, I don’t always have all the facts; so even when I have a very strong opinion, I am open to opposing views and to changing my mind.
I love a lively debate on almost any topic.
When I’m wrong, I admit it, and I try to admit it to anyone who I may have influenced with my previous, wrong opinion. It’s almost a compulsion for me. The more wrong I am, the more public I try to be as I make things right.
If you know me well enough to already know the above, then you will understand why I have written this post. If we haven’t had the chance to meet, you may read this and think it is just some kind of shill post from an Oracle employee. That’s OK; I would probably have thought the same thing a few short months ago.
The vast majority of my career has involved working with Oracle databases as a developer for Oracle customers. I have always believed that Oracle makes the best database available (its commercial Oracle Database, I’m digging into MySQL and Oracle’s NoSQL database and I’m sure we’ll talk more about those at another time.)
Bottom line: If you can afford Oracle Database, use it.
On the other hand, over the years I had formed some negative opinions about Oracle as a company. They didn’t disappear the day I started working for Oracle, but they have been fading away steadily, as I learned about Oracle from the inside.
A big, heartless corporation?
We’ve all seen the stories depicting Oracle as a monolithic company that only cares about the bottom line. Before I joined Oracle, I rarely noticed any instances of Oracle giving back to the community or helping those in need.
Now that I have an @oracle.com email address, I get several emails a week looking for volunteers to help with one charity event or another. It reminds me of how I never notice a certain type of car on the road until after I buy one myself. Now that I’m working at Oracle, I see Oracle in my news feeds all the time. For example, I’ve started noticing projects such as the Raspberry Pi weather station or Kids coding events when they pop up.
I guess it’s just a matter of my personal awareness. If something isn’t in my current focus (or reinforcing my current bias?), I see the attention-grabbing headlines, which (as we are used to in 21st century media) tends to the negative, rather than the positive.
I have to admit: when I accepted my new position, I felt a little twinge ofdread: would I face a soul-crushing grind, with too many hours worked and a bare-bones benefits package?
My dread was completely mis-placed.
The insurance package, educational opportunities, and internal perks are some of the best I’ve ever had.
Sure, there’s some red tape and progress reports and all the typical things that come with a technical job at a company with over 130,000 employees. But I have never had this level of freedom to shape my own work. I am able to use and expand my strengths, while being supported and mentored to improve my weaknesses.
Stuck with “old” technology?
Over the last few years I’ve been using all sorts of new fun stuff, including NodeJS, AngularJS, and document databases. I’ve dabbled with graph databases, a bit of Java, and all kinds of cloud products.
Once again, I was so wrong. I have seen (and am working on) many projects in all kinds of languages and technologies. I’ve learned about Oracle products using all of the technologies I’ve been interested in and many more that I had just assumed Oracle would not encourage.
My list of “Ooooh, I want to get involved in that” projects here at Oracle gets longer every day.
I feel like a kid in a candy store.
Open Source and Oracle – Really?
As you may have noticed, I am the Oracle Developer Advocate for Open Source. One of the reasons I applied for this position was that I’d always thought that Oracle was against open source and I would have a small, possibly quixotic chance to nudge Oracle towards open source. I expected to have a lot of push back on anything open source.
What I found, instead, was that almost every one of my “brilliant ideas” for getting Oracle interested in open source was already in place or in the process of being implemented.
Much to my surprise and pleasure, I find myself playing catch up.
Allow employees to contribute to open source projects: An existing approval process was already in place and anyone interested just needs to apply. I have applied.
Support Oracle and non-Oracle owned drivers for languages more often used with open source projects: Not only already existing, but one of my first assignments was to create an entry level tutorial and some examples for the cx_Oracle Python driver.
Can’t learn anything new if you think you know everything
I often say that “I learn more from being wrong than I do from being right.”
In my first four months inside Oracle, I have learned an awful lot from my inaccurate perceptions about this company. I expect to be learning lots more in the years to come.
Does this mean I agree with everything everyone at Oracle says and does? No way (except for my manager, of course). But I’ve now learned that many of my beliefs were just that – things I believed, rather than things I know.
The more knowledge I acquire about Oracle, the more glad I am I took this job and the more optimistic I am that open source developers will “catch on” like I have.
Who knows what the future holds for me, I enjoy this position and I hope to stay here for a long time. But, if something ever does draw me away from Oracle, I will be quite a bit smarter and hopefully I will be less quick to form negative opinions from limited data.
Following up on a previous post, I wanted to dig a little deeper into the idea that database administrators have a higher resistance to open source in the database than programmers.
Searching the web, I found very little on DBAs being either for or against open source. I decided to call a couple with whom I’ve worked over the years.
First, I spoke with the most experienced DBA I know; he’s been at it longer than anyone I know. He follows a very strict set of rules he’s developed over the years, but I’ve never seen him just say no to a new idea without a good reason.
I assumed he would be open but cautious towards open source.
Note to self: “Stop assuming.”
I explained what I was doing and asked how he felt about running open source PL/SQL in the database. The first thing he said was, “I download all kinds of PL/SQL code. I trust it, because I can go through it and verify it myself.” He also said, “If I can see the source code, I don’t have a problem with it.” He wants to be able to review anything that gets deployed to ‘his’ database
In his long career, the resistance he’s seen to open source has always come from management and/or the legal department.
He has seen the most resistance when he was working for companies who’s product was proprietary database software or companies with policies dictating that all software must have a license and a support contract. When working at companies where the database was mostly used for internal applications, he’s tried to use open source whenever it was available.
Well, that was encouraging!
Next, I spoke with a person I worked with years ago who fits the stereotypical definition of a DBA. He’s very focused, methodical and always keeps “his” databases running smoothly.
He told me that he never really thought about open source but added: “I often download snippets identified through online searches.” We talked for a bit about different licenses and his opinion was always the same: as long as he can review the code before he installs it, that’s fine. Open source vs. proprietary doesn’t matter so much, assuming the specific license works for the project.
Even more encouraging!
Finally, I spoke with a friend who does a little bit of everything. He’s been a system admin, a DBA, and a developer. He is constantly exploring new technologies and programming languages. We’ve had many discussions about open source, so I know he’s not against open source in any environment. I asked him about the resistance he’s encountered when trying to use open source.
He said, “The company environment/policy would determine whether or not I would run OS in the database. If we’re developing a closed source product, we wouldn’t want to include open source that had license terms that require us to open source our software.”
He told me about a coworker who had been “burned by a restrictive open source license on products that he’d used before.” Basically he had included some open source components in a proprietary application, and had not read the license carefully. That license required them to open source the company’s product, which of course was not an option. He had to remove those components and build his own.
Clearly, if and when you are going to incorporate open source code (or any code you don’t own), you’ve got avoid making assumptions, and perform due diligence on the licensing side of things.
While I realize that a sample count of three is not sufficient to draw a solid conclusion, common themes were clear:
When installing code in the database, regardless of origin, DBAs want to be able to review the code. It doesn’t matter if the code is open source, proprietary or internally developed. “Trust but verify” always applies.
Company management tends to be more concerned with the open source label than the people who work with the code.
The actual license terms matter, not the fact that it’s open source or proprietary. There are many different types of each.
We are looking for a PL/SQL package to solve a problem in our application and we find two that should work. One is open source, the other is proprietary and its code is wrapped.
Both come from reputable companies.
Both licenses allow us to use the software without restrictions.
The open source package has an active user community with frequent commits to the project.
The proprietary software has good documentation and is updated regularly.
Company management will approve either choice.
Both are free.
Which would you recommend to company management to use, and why?
I saw this on twitter a few days ago. (Disclosure – @sfonplsql is my boss)
The part that caught my attention was
“easy to say “trust open source” but seems like DB mgrs and devs quite reluctant to put OS code in database.”
This attitude isn’t restricted just to databases, I’ve seen it regarding all types of software. In fact there was a time where I didn’t trust an application simply because it was open source. But then…
My thinking started to change a few years ago
(It’s been a few years. I’m making this as accurate as I can remember.)
I was working on a government contract and we were looking for some bug tracking software. We were told it had to be very inexpensive. I suggested a very popular system that also happened to be open source. The software met all of our needs, it was free at the basic level and there was paid support available if we needed it. We started moving the proposal up the approval chain (did I mention government?). Everyone agreed that it would be a great solution.
When it reached the final approval level, however, it was simply rejected. We asked for the reason and were told “It’s open source, we can’t trust it. If you want to use it, there must be a full code review looking for security issues and unknown bugs.”
I’m rarely surprised by the illogical decisions I see some managers make, but this one caught me completely by surprise. By which I mean: when was the last time we checked for security issues in a commercial package? Just because we pay for it, it doesn’t have any?
I began to research proprietary options but of course the big name applications cost a big name price (sure, some of them were worth the price, but we had a small – and unchangeable – budget already allocated for the project.) The only options that fit in our very limited budget were not-ready-for-prime-time applications by companies that just didn’t seem to be putting much effort into maintaining and enhancing their product. They also had smaller install bases and less frequent updates than the original open source solution.
We chose the two that looked most active and sent them in. We were told that either of those would be fine. No review needed.
I set up a meeting with the approval chain.
I projected the code from the open source application on the board, and clicked through a few pages. I said “Here’s the code from the first app we proposed. You can see that it’s fairly complex and it will take a significant amount of time to do the requested code review. We have some talented programmers we can put on this and I’m sure we can do a good review.”
The person who asked for the review replied: “That’s why open source is a bad idea. It would cost too much to do that.” I pointed out that the ability to review, change and even fork the code is what makes open source so valuable. I pointed out that we know next to nothing about the people behind the approved proprietary solutions, we have no way to review the code, and if they shut down we can either limp along on the current revision or migrate to another application.
At this point, I suggested we evaluate the options not based on open source vs proprietary, but how likely it is that the software would be improved moving forward, and what our options would be if the application was abandoned.
Feature wise, the open source product was far ahead already so we looked into support and update frequency.
One of the proprietary options hadn’t had a release in a couple years and the developers hadn’t responded to a forum post in months. This was a bad sign, and we decided to drop that alternative
The other option had a fairly active forum, but there were a lot of posts from users asking for help getting around problems and configuration issues. The documentation was sparse, and judging by the forum posts, had a few inaccuracies. They seemed to be releasing yearly with mostly bug fixes and some minor features. Upgrades cost a small amount each time. Not terrible overall and it would be something we could live with.
The open source product had a very active community with frequent forum posts, pull requests (made and accepted) and a nice selection of add on modules. The documentation wasn’t great, but what was there seemed accurate. It seemed to be going strong and growing.
A couple weeks later, we were using the open source solution, no code review needed (but it was an option if we wanted.)
What’s the point?
The above is what it took to shift my thinking. I’m not advocating only open source. This is not an open source vs proprietary debate. I try hard to stay away from extremes and absolutes.
The point is, ignore the labels, figure out what matters in your situation and make informed decisions.
I’ve seen the above scenario play out a few times over the years and it usually ends the same way.
I would like to dig into why some people seem to instinctively mistrust open source. (It’s not just manager types.)
I will follow this up with a couple situations I see every now and then. I’ll also look at the specific situation of open source in the database.
Help me out.
I would like to turn this into a full discussion, so please leave comments with your experiences from either side of the situation. If you’re currently going through this and would like some help, let me know and I’ll go find us some information.