What's your stack?

[j0hnsmith]

Why no Vagrant?

I forgot vagrant.

I can now put the following into any template:

[form_table action="/admin/account/whatever"]
   [text name="username" required="1" jsValidate="checkUsername(this);"]
   [password name="password" required="1"]
   [text name="email" label="E-Mail Address" required="1" format="email"]

   [separator]

   [select name="category" required="1" data_source="table(account_categories)"]
   [boolean name="add_api" label="Add via API?" value="1"]
   [textarea name="description" size="500x200"]
   [submit]
[/form_table]

Put that into any template, and the template engine will turn it into a nice two column table with all necessary labels and fields, Javascript validation, etc.

This is more or less what WTForms does except it does server side validation instead of client side (IIRC, it's been over a year since I used it). Upon form submission it can return a partially filled in form with errors in the necessary fields. There are libraries that can add client side validation.

As far as I can tell the tools you use seem to do more or less the same as the tools everyone else uses, however we don't usually write our own, we happily leverage other people's work whereas you seem to write all your own tools.
[/QUOTE]

I'm moving towards NodeJS (javascipt in general) and Go.

To those who use WTForms and Jinja, learn Angular, and then give 0 fucks. These days I basically use Flask to handle a RESTfull API, and then use Angular to process all the visual font end stuff. Works way better than writing Flask templates and that kind of nonsense.

Agreed, I love Python but I'm (reluctantly) moving towards Node and js in general.

Rage9, are you writing angular stuff "by hand"? By that I mean that I often autogenerate form HTML from a WTForms class, which I can often autogenerate from a model (most forms aren't doing much special). Is it possible to autogenerate the angular code for these cases?

Get an OPTIONS call to your api to return a json serialized version of your model fields, then you can get angular to generate the form for any model and have client side validation automatically (min length, required etc, obviously uniqueness constraints will require something extra).

I find Angular a paradigm shift, you focus on state instead of the dom. It's not an easy ride but the result is worth it.

 

[Nerd Muscles]

Agreed, I love Python but I'm (reluctantly) moving towards Node and js in general.

I'm curious, why move towards Node? I've asked a few other people and the answer can usually be summarized as "because everybody's doing it", so just wondering if you have specific reasons.

If I'm working on a project that involves any sort of data processing or third-party APIs (which a lot of my projects do), I can't imagine any benefits of using node.

In fact, python-requests, pandas, NLTK and other big data tools will see you with performance benefits node.js users only dream of having (since Pandas and NLTK are written in super-optimized C, not V8 javascript).

Again just curious, not knocking your opinions/choices.

 

[Rage9]

Rage9, are you writing angular stuff "by hand"? By that I mean that I often autogenerate form HTML from a WTForms class, which I can often autogenerate from a model (most forms aren't doing much special). Is it possible to autogenerate the angular code for these cases?

It's funny, it's taken me so long to answer this mostly because I only care to post in this section of the forum once and a while because I find it of such little value.


Anyways, I guess yes, by hand if I interpet your question correctly. Writing angular forms is much easier than most methods though, you will still have to check your work on the backend. That being said, I've worked with WTForms and it is a mile behind doing it Angular style.

 

[Rage9]

I've been thinking along similar lines lately but I don't have much desire to learn JavaScript.

....

Do you have any recommendations about how to fill the knowledge gap in order to get up to speed with Angular? (Definitely only interested in JavaScript on the client side)

Now I don't understand this out of web developers. Javascript is growing at an exponential rate. Now when I only worked with jQuery I never actually bothered to learn Javascript. I know this is the sad truth.

The truth of the matter is if you wish to learn Angular you will have to learn Javascript. Point blank. There are no alternatives.

As for how to get up to speed with Angular, there are no substitutions for just doing it. Learning how to put it together, and honestly the hardest parts are learning to write directives and services. If you don't know Javascript, good luck bros, Javascript is really not that hard.

 

[Rage9]

I'm curious, why move towards Node? I've asked a few other people and the answer can usually be summarized as "because everybody's doing it", so just wondering if you have specific reasons.

If I'm working on a project that involves any sort of data processing or third-party APIs (which a lot of my projects do), I can't imagine any benefits of using node.

In fact, python-requests, pandas, NLTK and other big data tools will see you with performance benefits node.js users only dream of having (since Pandas and NLTK are written in super-optimized C, not V8 javascript).

Again just curious, not knocking your opinions/choices.

There is no one that will hold a gun to your head, the truth is the web is evolving. PHP sucks. Ruby sucks. Python is cool, but honestly if you look at the speed of Python it too sucks. Javascript has had a heavy hand in it from browser developers and looks to be a promising platform. As far as I'm concerned, write whatever makes you money. However you can not ignore the shift that is happening or you'll get left behind.

 

[shindig]

Mobile/Games:
C# + Mono
Java,
php (POST/GET)
sqlite, mysql, mongodb, xml,

Web:
js/jquery,
html,
xml,
basic php

Electronics:
My newest addiction: Arduino - BuildProcess C/C++ to program the physical world....it's fucking amazing.

 

[danny]

Node and Angular are really great. Javascript may not be the best language for anything but as far as I'm concerned it's the best choice for the one you use for almost everything. What they both got right is having everything built on some implementation of modules. After all these years of convention over configuration and blah blah blah MVC framework blah blah it's really refreshing to have everything really loosely coupled.

Aside from the merits of modules, Angular does a really good job of having the DOM not be fucking awful. With Angular, jQuery being born doesn't even seem like a historic event anymore. 2 way fucking data binding that just works, praise jesus.

The thing about Angular is that the documentation is pretty awful. You could read the whole getting started guide and have no idea that a controller can just be a function. It reeks of ugly premature optimization, but once you get how simple it is you actually can get really great stuff done in a few lines of code. As you scale the modules you create will be apparent and they'll just work without breaking anything else.

Bootstrap is perfect. Everything just works. If it's not right for your requirements change your fucking requirements. It's still HTML/CSS and it's still fucking verbose, but it doesn't surprise you and with Angular you're not worrying about the DOM anyway so I love it. You can make it a little more readable with Angular directives, but I'm against that right now. Maybe I'll find a balance but for now looser is better.

Mongodb is good enough. I'll always be a relational database advocate, but mongodb is just more practical for more applications right now. I used an ORM on top of it and then questioned why the fuck I needed one, which is something nobody can say of any SQL flavor.

I guess Git is obvious at this point but I was at a place that stuck with SVN for way too long.

Vagrant is nice. Please use a VM.

Scala is what exciting things will be done with.

Python has so many merits that it has too many merits to be in front. Javascript has a balance you'll never get with everyone running wild in Python.

The fact that CSS preprocessors are necessary is a shitty reality, but I'm a LESS guy right now.

 

[harrymouni]

Android
Eclipse (oh jesus i hate you so much but it's second nature to me now)
Android Studio (way better IDE but Gradle build system is a POS IMHO)
Smali/Baksmali (Android bytecode decompiler)
DexProtector (APK obfuscator)
Notepad++ (Eclipse can be so bad, especially search/replace, that I edit a lot in Notepad++ and just compile from Eclipse)

SourceTree for GIT. It's fantastic. I recently moved from msysgit. Inb4 'real coders use git bash'

iOS
Xcode duh
Sublime Text (fantastic editor but I don't use it as much as Xcode isn't that bad)

 

[absolute]

Alright I'm going to give Node a shot... fuck. Already using Angular for everything front-end and couldn't be happier. Did a rewrite of a sizable app last month and ended up replacing about 5000 lines of jQuery with maybe 500 lines of Angular (not counting any html changes).

 

[editeur]

Javascript on server is horrible. No multithreading (you have to run an instance for each core), memory leaks, unreadable spaghetty code style due to callbacks. It looks nice when you have a small project but when you do anything more or less large it goes out of control very quickly. I'd take erlang instead of node any time for server software.

 

[absolute]

Javascript on server is horrible. No multithreading (you have to run an instance for each core), memory leaks, unreadable spaghetty code style due to callbacks. It looks nice when you have a small project but when you do anything more or less large it goes out of control very quickly. I'd take erlang instead of node any time for server software.

I get that impression too... depends on the project I guess? Anything real time is a PAIN with rails, laravel and the like.

 

[Rage9]

Javascript on server is horrible. No multithreading (you have to run an instance for each core), memory leaks, unreadable spaghetty code style due to callbacks. It looks nice when you have a small project but when you do anything more or less large it goes out of control very quickly. I'd take erlang instead of node any time for server software.

So Javascript is like every other moderately popular web development language but faster? Callbacks are... different, but after getting to know how to use them it's really not that bad. I think Javascript some times gets a bad wrap because of callbacks. Javascript is kind of a shit language - but it's a relatively easy, straight forward shit language.

The problem is Javascript is so ingrained in web development and it has major backing from multiple major tech companies that are dead set on making it fast. This you can not say as much about many of the other popular web development languages. To me, the writing is on the wall. There is also always Dart, which we could hope catches on.

I can't comment on erlang, I've never heard of it until now. According to wikipedia it's been around since 1986! Good luck getting paid in that though, I'll stick to what makes money. Such is tech.

 

[mattseh]

I think Erlang can make money, if one is in the right circles.

I am really liking golang's concurrency model, (goroutines + channels) it seems a lot neater than greenlets / callbacks / etc. I haven't made up my mind whether it makes sense to build web projects with it instead of flask yet though.

 

[editeur]

The problem with golang goroutines is that you cannot kill a hanged goroutine from outside. So it is very possible to stop the whole server by just one bad goroutine.

Rage9, you sure heard of Erlang. For example, WhatsApp is built on Erlang.

 

[Mahzkrieg]

Clojure (and Clojurescript) also has Go-style concurrency available as a library called "clojure.core.async".

Here are Go and Clojure code examples side by side: https://gist.github.com/danneu/5941767

It's a very pleasant abstraction, especially after being underwhelmed by Node on client projects for so long.

You can compose your application from small "processes" (loops that execute concurrently) and then hook up input and output channels to them for coordination. Most immediately useful on the client-side where you have a single thread, but I use concurrent loops on the server side as a layman's cron job.

That starts a concurrent loop that busts my cache every 30 seconds. I'd drop it in my `init` function that runs when the server boots.

 

[mattseh]

The problem with golang goroutines is that you cannot kill a hanged goroutine from outside. So it is very possible to stop the whole server by just one bad goroutine.

Rage9, you sure heard of Erlang. For example, WhatsApp is built on Erlang.

I'd be interested to see how you can hang a goroutine without it being a bug that should be fixed.

 

[editeur]

I'd be interested to see how you can hang a goroutine without it being a bug that should be fixed.

For example Infinite loop under some conditions (bug) or blocking infinitely in i/o (might be bug or not bug, depends, usually not). In erlang/otp you just specify the timeout for handle_call of a worker and can restart the hanged process if timeout error occurs.

 

[Jake232]

For example Infinite loop under some conditions (bug) or blocking infinitely in i/o (might be bug or not bug, depends, usually not). In erlang/otp you just specify the timeout for handle_call of a worker and can restart the hanged process if timeout error occurs.

If you're launching your "threads" with a timeout just incase they hit a bug of yours and may loop infinitely, you're doing something wrong. The IO requests in Go also support timeouts, so that's not an issue.

 

[editeur]

If you're launching your "threads" with a timeout just incase they hit a bug of yours and may loop infinitely, you're doing something wrong. The IO requests in Go also support timeouts, so that's not an issue.

In erlang/otp ALL blocking requests to gen_server workers have timeout, so you just don't care about writing all the logic yourself. The philosophy of errors handling is "let it fail". When something wrong happens the supervisor process just restarts a worker, and optionally cleans the resources and logs the error. You configure how many restarts per time interval you allow before it will crash and don't have to write all this stuff yourself from the scratch, it's built in OTP library.

Errors do happen, sometimes it is bug which needs fixing now, more often when bug is rare you just restart the worker, and don't care till the the next release. It is not always errors in your code, it can be i/o or integration with third party software. This saves a lot of headache.

 

[gutterseo]

Linux