Kotlin is a general purpose, open source, statically typed “pragmatic” programming language developed by “Jetbrains” and endorsed by Google. As a light, nimble way to take advantage of the vast Java ecosystem and libraries, without the weight of Java code, spoiler alert…it’s gonna be pretty awesome. Now that being said, should you drop everything (including JAVA) and start learning KOTLIN?
Not necessarily. As we’ve said before stick to your fundamentals/basics, remember: “Newb programmers will think in terms of languages, -OMG, my career is based on THIS language- The reality of the situation is advanced developers will move from language to language, from framework to framework, depending on the requirements of the job at hand, depending on where the work is.”
So what’s the big deal about KOTLIN? Well it’s more about what KOTLIN represents… it’s a lighter/faster version of JAVA, it’s pretty versatile in terms of what it can be used for (including android apps), and to put that into perspective, “lighter languages tend to win out over other heavier, more verbose languages”. With computers getting more and more powerful and faster and faster, the preferential choice is given to languages that are quick, adaptable and versatile, and KOTLIN checks all these boxes.
Now, like we said in the second paragraph, there’s no need to drop everything and worship new and fast, especially if you already know JAVA, JAVASCRIPT, C#, PYTHON, PHP, etc… they share so many similarities that you could jump into them relatively easily. If anything, rejoice guys! Stick to you basics and your job may be faster and easier…and hopefully more fun too.
Click here for some hardcore mountain-driving scenery, which will turn into city driving, but not before we give RUBY the slightest little dig…mwahaha.
Enjoy!
C# is probably Microsoft’s flagship language … is it worth learning 2019?
Well, is it worth learning? “If you want to interact with the Microsoft(MS) stack: …building web-based apps that are going to be interfacing with back-end MS technologies…AND you learn C# if you want to get into game programming with UNITY as an example”
Based around JAVA, this modern language was built by MS to function like JAVA but with some “robust” differences… But enough about that, let’s talk jobs!
There are lot of job opportunities working on .Net architecture (ie: web apps), mostly with big corporations…however most of them will require certification in C#. The good news, if you try it out and decide that C# is not for you, you haven’t wasted your time at all, because “all these modern languages(C#, JAVA, Dart, ,etc.) are based on the same principles [more or less]”. If you’ve learned C#, it’s like 80% transferable, “…you cannot lose when you learn a programming language…”
Check out the VLOG for a more in depth explanation, some wisdom about the game developer experience and a little heart2heart…awww. Enjoy!
So, you’ve been a developer for maybe two or three years? You’ve got some gigs and you’ve gotten paid and now you’re starting to work with the big fish… You’re maybe even working alongside other developers with 5-8 years of experience and suddenly you feel a kick in the pit of your gut… “WTF am I doing here?”
“I’m wayyyy in over my head, everyone knows what’s going on; they get their work done faster, they know which languages to use for any given situation. I don’t belong here.”
Ya just got DIS’d, son!
Yup, developer imposter syndrome…’d.
Now for some of you I may be spot on and for others, you either have felt this way and gotten past it <bravo>, or you haven’t crossed this particularly crappy bridge yet. And though I know it’s hard to come to any universal agreement on the internet, I think even in the back of our mind we can understand, sympathetically, “You can never ignore the emotional aspects of anything you do in life; especially career.”
Everyone Gets DIS’d, Bro:
(yes, I’m enjoying the hell outta this acronym)
But seriously, as unpleasant and humbling as these feelings are, they are completely normal. Everyone has felt these feels; even outside of the development field (it’s just called plain “Imposter Syndrome”, I know IS = boring acronym, but you should look it up). Ironically, feeling like we don’t belong (an Imposter), is something that everyone feels at one time or another. And perversely, it’s kind of a milestone; it means you’re “moving up in the ranks” and coming into your own by being around other more experienced programmers/devs who you should be taking the opportunity to learn from, or if you’re a little more solitary in your work, branching out finding a community you can learn from and feel supported in.
Alright I Got DIS’d, Now What? (Still not tired of it, mwahaha.)
Guess what? “There is no unicorn developer”, that is to say there’s no one that know every language, has been in every situation and knows everything. If there was, clients would just hire him/her and there would never be a need for anymore programmers or devs. Check out this vlog: if for no other reason than to see me freezing my butt off in the cold as we switch from a tight “man on a mission” shot to FPS mode and then the car for some “real talk”… It’s a fun way to talk about what can be a pretty frustrating subject. Me? I’m gonna sit here and think of how I can work this acronym into a sentence where I DIS your mom! OOOOOOHHHHH, snap!
Enjoy!
A little while back I asked my brother (a big Java nerd) to explore using Ruby to rewrite a threaded Java web application – a site monitor.
The results have been really cool so far. So cool in fact that I asked him to write an article on his experience.
NERD ALERT: This article is written for programmers.
–
Writing a standlone, threaded application using Ruby On Rails
By Richard Mischook
Awhile back I wrote a Java application designed to monitor web sites to ensure they are up and running. The Site Monitor service is hosted on the web and allows a user to sign up and add a site to a database that is routinely monitored by the engine.
When the engine finds that a site is down, a log entry is made and the owner is sent an email letting them know that they might want to look into it; if and when the site is back up, another log entry is made and once again the owner is emailed.
The development of the application took a little longer than expected and alas, has had a number of teething pains. On more than a few occasions we have asked ourselves if another set of implementation choices might have been better, such as a technology other than Java.
In addition, rather than delivering the tool as a hosted service, would it make sense to deliver some sort of standalone application that a user could download and run on their own desktop?
Around the same time I had been messing around with Ruby On Rails which as many of you will know, is a web application framework build on the Ruby scripting language. One of the central promises of Rails is a framework that allows the delivery of powerful results quickly.
The questions then:
Could the Site Monitor be delivered using Rails and if so;
How long would it take and would it be better than the existing solution?
Requirements
The Java version of Site Monitor is actually reasonably sophisticated and supports a range of features which I will not exhaustively list here.
Instead lets look at the main features we wanted to see in the Rails version:
Support for multiple sites checked concurrently, with sites double or tripple checked to make sure they were really down.
Support for multiple control sites to verify that the internet connection to the outside world is up
Support for multiple notification email addresses and mobile phone numbers (for SMS notification)
Configurable by the user with the choices saved to a file that is loaded when the engine is re-started
An Ajax-based user interface allowing the user to a) configure the engine and b) capable of displaying engine activity
An easy to install application suitable for Microsoft Windows users.
An example of the user interface can be seen in the screen shots. The web interface leverages the Ajax support built into Rails and allowed me to deliver a richer user interface than normally found in traditional web applications
In fact as I’ll show later, some limitations in the Ruby threading model made it necessary for me to use the Ajax support in a way that I had not originally anticipated.
The hardest requirements to fulfill were going to be the first and the last:
i) support for concurrent checking and ii) an easy to install application.
Most of this paper will be about how I tried to address the first requirement, but I will discuss the second as well.
Concurrency in Ruby
In the original Java version of the application, a timer ran from time to time (say once a minute) and invoked a method to load a list of sites to check from a database. A Java thread was retrieved from a thread pool for each site that required checking; this meant that more than one site could be checked at a time.
This was important because it might take awhile to finish checking a site since we were actually double or tripple checking sites that did not respond (in order to avoid false positives). Without threads, it would take significantly longer to check a stack of sites as each site would be required to wait in line (so to speak) to be checked.
The good news was that Ruby has a threading model and it seemed very easy to implement. The check_sites method below (which is abbreviated for clarity) illustrates the main logic which is essentially:
for each site (line 2), spawn a thread (line 3) and execute the block of code from lines 3-17
check the site (line 5)
if the site does not respond (line 7) and we have verified count number of times that the site is down, let the user know (line 11)
-
1 def check_sites(sites)
2 sites.each do |site|
3 threads < < Thread.new(site) { |mySite|
4 begin
5 ping_site(mySite) # actually ping the site
6 handle_up(mySite, ...) # site is up so let user know IF site was down before
7 rescue ConnectException => c #if here then no response
8 count = count - 1 #count is set to some value above (not shown)
9
10 if count == 0 #log it and send mail
11 handle_down(mySite, ...) #another method that logs and sends email not shown here
12 break;
13 else
14 #check control sites [not shown]
15 end
16 end
17 }
18 end
19 threads.each { |aThread| aThread.join }
20 end
-
Note that there are few key bits missing from the above so don’t expect it to run by itself. That said the principle is sound and means that given an array of sites to check, processing will happen concurrently. But there is an issue that I did not anticipate: any code calling this method will block until all the child threads created in check_sites are done. This is a problem because what I had planned was to define a method like the following:
1 def start_engine
2 # load some sites ...
3 while(true)
4 sites = ... #not shown - code to load sites
5 threads = []
6 threads < < Thread.new(sites) { |mySites|
7 check_sites(mySites)
8 }
9 threads.each {|t| t.join}
10 sleep(30) #sleep for 30 seconds
11 end #end of while loop
12 end
The start_engine method starts a loop that:
Loads a list of sites to check (line 4)
Creates a new thread and calls the check_sites method with the sites (lines 6 and 7)
Goes to sleep for 30 seconds (line 10)
The plan was for the sleep() call to happen immediately after calling check_sites but before all the checking was done, i.e. not block. Unfortunately Ruby doesn't work that way; in fact what actually happens is that the call to sleep() only happens after all the threads in check_sites have finished executing.
The other really big problem is that since the while loop is always running, the Rails server (e.g Webrick or Mongrel) is always blocked meaning it cannot serve any further requests - such as my web browser Ajax call to find out the current status. All of this meaning that I needed another way to do the job done by start_engine, i.e. another way of periodically calling check_sites.
You may be wondering why I wanted to run this in a Rails server at all? One answer is that I wanted to do the user interface as an Ajax-enabled web page but also wanted the user to be able to start the server and have the engine running in the background. Alas this was not going to work.
I thought for a second that I might need to think about spawning some seperate processes (rather than relying on Ruby threads), but that looked like a lot of work. I did look at using the backgroundrb library (a Ruby library for simplifying distributed, interprocess communication) but it is not supported on Windows (crappy toy operationg system *&&^%$). Instead I decided a compromise was in order.
Using Ajax to Run the Engine
The problem then: how do I replace the start_engine method such that I can get the server code to periodically check my sites (while allowing other stuff to work)? Well the answer simply enough was to embed a Rails periodically_call_remote tag in my index.rhtml page; the tag sends an Ajax request every so often to the server that gets it to call check_sites. In fact I also embedded a second periodically_call_remote tag that refreshes the user interface console so the user sees what is going on.
There is still a problem though: check_sites can still take some time if you are checking more than one or two sites and any fail to respond. While this is happening (the checking), the Rails server will be unable to answer any UI refresh calls (coming from the second periodically_call_remote tag). Still, not the end of the world as this version is meant for a single user checking a very small number of sites. On the other hand frankly, this is not the most elegant solution and one I would like to change.
In fact I did look at trying to spawn the Monitor in a seperate process using a fork call. Unfortunately the implementation on Windows is broken (anyone see a theme developing here?) In fact the Programming Ruby book's section on processes does suggest that support for forking is limited, which is better than the API documentation's thunderous silence on the matter.
Lesson then: Ruby is Unix-centric by default - live with it.
I did try and get around it by installing a set of gems associated with the Win32 Utils project - specifically win32-process. I did have some luck with this but not enough (the main issue having to do with class loading woes).
I do think that there is some potential in this route, but it would require me to spend a bit more time making sure the Monitor code is free of any Rails dependencies. In the meantime my next little project may be to start playing with win32-process to see if I can get it to work the way I think it should work.
Packaging Up the Whole Thing
I mentioned earlier that one of my other requirements was to try and package this thing up in such a way that I could distribute it as a single, easy-to-use windows exe or equivalent. What I was in fact hoping for was the ability of users to download the whole thing without having to install Ruby or Rails or any of the gems used by the application.
Now admitedly this was something of a tall order; but I was led to believe that it was worth looking at given an article entitled Distributing Rails Apps: A Tutorial.
Unfortunately my attempts have not met with any success; in fact when running the various tools I'm not really getting any feedback that indicates what, if anything went wrong, other than the fact that things just are not working (to be fair I only spent about 15 minutes on this). So I have added this to my list of things to look into; in fact it's top of the list since not getting this working will make distribution that much harder. I'll post a follow up if I have any luck on this front.
Conclusions
The application I re-built in Ruby actually works pretty well and the Ajax user interface does what I hoped it would do - even if it doesn't win any beauty contests. But Ruby threading, while easy to implement, suffers from a few limitations such as:
When spawning new child threads, the parent thread needs to block waiting for all the little kiddy threads to do their thing.
This is made even more of a pain by the fact that the main Rails runners, Mongrel and Webrick, can only handle one request at a time - period. It would be nice if someone could write an easy-to-use proxy that wraps a couple of Webrick/Mongrels so that you can have a single container that supports concurrent requests (yes I know you can do this with Apache but that requires that I do some work when all I want is a development environment that can support say - 2 concurrent requests).
Which brings me to another issue with Rails in general that has nagged at me: its reliance on process-based request handling. Each request has to be handled by a dedicated process which would seem to have the potential for limiting the scalibility of a Rails application.
Now I know that this debate has been raging elsewhere on the Interweb and I must confess I have not looked into it in great detail. At the very least it would suggest to me that anyone designing a Rails application really does need to keep that in mind, especially with regard to managing connections to databases. While that's a side issue, I invite any comments (and pointers) on the matter.
One last thing - my main interest in Rails has been fueled by my ever increasing lack of patience. Not so very long ago I was happy to spend days trying to understand some new API or product that promissed to be the next cool thing. This, some might say, was a prerequisite for becoming a Java J2EE developer.
These days, I have a wife and a baby, TV shows I want to watch, books I want to read - in other words - lots of other things I want to do. I want to get my work done NOW. I want to work with tools that are enablers - rather than impediments.
We're not there yet and truth be told, Rails is very good for developing data-driven green field web applications; but there are limits to what it can do and one wonders if it can (or indeed should) grow beyond these.
by: Richard Mischook. www.killersites.com, www.killerajax.com
On September 14 and 15th I was at the RailsConf event in London. I don’t have the exact numbers but I’m guessing that there were somewhere between 500 and 1000 attendees. The age range included the expected contingent of 20-something geek types but perhaps surprisingly a large number of obviously older folks were also in attendance (the latter category sadly including me).
I say surprisingly because Rails is a relatively young technology that I think is still in its ‘early-days’ phase, albeit with a rapidly growing mind share. Despite this a number of maneger-types were on hand and presenting; this was particularly interesting to me as I am very interested in the issues surrounding using Ruby and Rails in the enterprise.
Before diving into a look at some of the details of the conference I will say that my overall impression is very good. I was reminded of the JavaOne conferences I attended in the late 1990s where the enthusiasm in the room was almost overwhelming.
Clearly the folk doing Rails are converts (often from Java) and believe that Ruby and Rails are better tools than much of what is out there.
Rails is fun
Rails developers are having fun: this is good because happy developers are productive developers; they are having fun because they are getting things done faster and spending far less time wrestling with the sorts of plumbing issues that kill creativity and make development a chore rather than a joy.
This fun flows from two things: the beauty of the Ruby language and the Rails framework. The Ruby language provides some very nice syntactic features that mean writing less code than would otherwise be the case with other languages.
Rails provides a variety of elements that make it fast and easy to deliver working code; some of the key features include the use of conventions rather than configuration (still allowing though for the overriding of those conventions), a number of great APIs for handling many web-application needs, the most prominent being perhaps an easy to use Object-Relational Mapping API (ActiveRecord).
Rails in the Enterprise
Rails is being introduced into the enterprise in the same way that Java was back in the late 1990; that is, by enthusiastic developers ‘sneaking’ it in. I heard a number of stories but one that certainly stuck goes like this:
(i) developer does quick prototype
(ii) developer shows prototype to manager who says it looks great
(iii) developer tells manager that he/she is ready to develop it in Java but it will take two or five or X time as long
(iv) manager says – but what’s wrong with this
(v) developer smiles.
Any new technology is bound to face reluctance from risk-adverse enterprise technology decision makers. This is (in my opinion) perfectly understandable; some good news though is that Sun has hired the main guys behind the JRuby project (allowing Ruby code to run in a Java Virtual Machine).
Currently JRuby will support running most Rails applications in a JVM. The roadmap for JRuby include a number of things including compilation of Ruby code to Java byte code. Speed of JRuby is currently not up to CRuby but this is the goal. For me the existence of JRuby signals Sun’s realization that the Java web frameworks are declining in popularity; for those of us in the (Java) enterprise, JRuby represents a possible risk mitigator if/when proposing Rails as a piece of a solution.
Performance and Scalability
Rails suffers from the same sort of performance and scalability issues as other frameworks but the approach to fixing these is pretty much the same as with other frameworks, e.g. tune your database queries, implement a caching framework, profile your code.
The flip side though is that delivering a result in Rails does appear to be significantly faster and involve writing less code. In addition Rails seems to strongly facilitate an iterative approach to development that is very attractive to those who accept the key tenets of the Agile school of thought.
Rails is Growing
Rails is growing fast: there are now some 300+ open source pluggins for Rails supporting a wide range of functions and APIs (for example messaging systems). The new Active Resource API supports treating a URL as a vehicle for doing CRUD using XML – web services without the overhead associated with SOAP.
Rails Development Tools
Tools support is growing: the next version of the RadRails Eclipse-based IDE will include support for refactoring; I asked the main developers about code-completion support (e.g. method completion) while acknowledging in my question the issues associated with doing this for a dynamic language. I was told that there was some work going on in this area and they hoped to be able to support it to some extent in the future.
Final Thoughts
Rails is an exciting framework for doing web application development that is I think in the early stages of a rapidly accellerating curve. The next year will I think be telling and it will be interesting to see to what extent Rails captures mind share and resources from other comparable frameworks.
It has been a couple of years since I moved (from in-house hosting) my Java based web applications to using an outside company.
When I was hosting my little apps from my Windows 2000 server (using Caucho Resin,) on a DSL connection, I never had a problem … probably because it was so small.
Since growing and moving to Tomcat on Linux, I’ve found that Java is not the most stable thing … it is not uncommon for Tomcat to lock up.
Contrast this to my PHP based applications (WordPress for example) and I have yet to experience a problem.
THE JAVA FACADE
The Java community loves design patterns (they need them with that overly engineered Frankenstein of a language …) so I’m sure they’ll understand this -> Java is heavy, whenever you start a Java process it like putting on 50 pounds – it slows you down.
The Java facade is the claim that Java is a light nimble thing … the JVM that is. It is not anymore. It once was say back in 1997.
I always wondered why Sun (a billion dollar company) could not get Java Applets to work whereas the relatively tiny company Macromedia, could with the Flash player?
… I’m ranting, so sorry.
CPANEL IS SCARED OF JAVA
Funny, when you activate Tomcat to work with a domain on CPANEL, it gives you a warning about how much juice Java swallows up … and warns against enabling too many Java based websites. It doesn’t say jack about PHP …
JAVA’S FUTURE IS IN LEGACY
It seems a contradiction, but I think that’s where it’s at. Java will become (strictly) a technology of the Enterprise (and legacy integration) while nimble languages like PHP and Ruby will be used to create the new innovative software.
Why?
PHP and Ruby programmers can (and do) code circles around Java developers. You can’t blame the Java developers: the Titanic couldn’t turn on a dime either!
I wrote my first script back in 1996 – some really simple JavaScript that validated HTML forms and presented users with ugly ‘alert’ boxes when errors occurred.
I always wondered why on Windows, ‘alert’ boxes looked so ugly?
… they probably looked good on Macs though.
Since then, I’ve written software for business purposes in perhaps 8-9 languages. Over the years, I’ve come across many ways in which people classify languages:
Object Oriented vs. Procedural vs. Prototype
Scripting vs. Programming
Compiled vs. dynamic
… and many more.
Recently a more practical way of classifying languages has come to my attention – classifying languages by problem-domain or in other words, context.
System Languages
Architectural Languages
Application Languages
I like this list, because it really conveys a sense of practical use for a language. I’ve hammered out the details below:
System Languages
… best used to build operating systems, hardware drivers etc. Fast and gives you low level (close to the core) access to the computer. These languages are used when speed is critical.
These languages include:
C
C++
Assembler
Architectural Languages
… best used to build frameworks that support (make easy) application building. Not as fast (at run-time) as system level languages, but they provide a higher level of abstraction that makes writing software quicker and more productive.
These languages include:
Java
C#
Application Languages
… best used to build the actual business applications like web shopping carts/stores, connecting to databases and creating the screens for users to interact with the database.
These languages include:
PHP
Ruby
Perl
Python
These language all allow for extremely fast development.
Programmers are freed from the low-level details that you have to contend with when working with architectural and system level languages.
The fact that they’re all scripting languages (that don’t need to be compiled,) adds to the ease of use and speed of development.
MY POINT
It makes for an interesting way to look at languages … and our choice of what language(s) to use for a given project.
This is the famous ‘PickAxe’ book that Ruby nerds talk about. A very well written book that is concise and to the point.
A COUPLE OF COMMENTS:
This is one of those books that reads very well. I had a hard time putting it down even though the coverage was deep – you’ll learn a lot about Ruby and maybe more about programming in general.
I never give the TOC of a book (that you can easily look up,) but I should mention 2 major divisions:
Part 1 is a tutorial that leads you through the core Ruby language.
Part 2 goes into the Ruby environment – the tools that you have available with Ruby. There’s a lot and they work well.
There is much more (advance Ruby concepts, Ruby reference) but I will leave that for you to look into.
FINAL COMMENTS:
What can I say … if you are using Ruby or you want to learn Ruby, you need to get this book.
A small book that takes a critical look at Java and other languages (Ruby, PHP, ) at a moment in time.
I say ‘at a moment in time’ because this book will lose relevance very quickly – even more quickly than the typical nerd book.
In a nutshell:
You get a brief history lesson on languages and their problems.
You get a perspective of the problems that Java developers face.
You get perspective on the subject from interviews with several big-wig names in the field.
You get an overview of Ruby and Rails.
My complaints:
The author likes to introduce his chapters with kayaking stories that are suppose to reflect what he is about to talk about … I would just skip those parts because I am not into kayaking.
Question of accuracy: he mentions (page 174) that PHP does not have enough structure. This is a silly statement given that there are SEVERAL PHP frameworks out there that provide the exact same structure as Rails – some even copy Rails.
Conclusion:
I liked the book and it was a worthwhile read. It has a few problems but it does open your eyes to things.
That said, the title of the book should have been: ‘Beyond Java and why I love Ruby’.
