transmit101

Is there anything to suggest these increases are not reflecting the increased baseline price of RAM, GPUs, etc?

If not then it is only a matter of time before other providers are forced into similar price hikes.

Nothing really stopping an agent from getting a key

It very much is possible to prevent an agent from having access to a key. For example, local encryption, Yubikey or other hardware device, or just running the agent in an isolated environment.

Yet I feel no inspiration to see those projects through to the end. I feel no connection to them because I didn't build them

For me, this is a key differentiator between “AI-assisted” and “vibe-coded”. With the former, I may use AI in many ways: some code generation, review, bouncing ideas, or whatever. But I engage in every step, review and improve the generated code, disagree with the reviews (and still contribute a good proportion of hand-written code, at least in the core business logic). In this way I retain sufficient ownership over the output to feel it is my own.

With vibe-coding, I feel exactly as you describe it.

I implemented the HTTPS-only Pages feature in this release.

I just wanted to say that GitLab is a great project to contribute to, with a very friendly and professional community! Definitely recommend to anybody interested in contributing to a project themselves.

[1] https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16273

[2] https://about.gitlab.com/contributing/

As it happens, I've got a couple of merge requests open to add HTTPS-only support to GitLab Pages.

If anybody is interested:

Rails: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16273

Go: https://gitlab.com/gitlab-org/gitlab-pages/merge_requests/50

Mixlr | Qt/C++ developer | London, UK | ONSITE | http://mixlr.com

We are looking for an experienced Qt developer to join our team and lead development of our cross-platform desktop app.

Mixlr is a live audio broadcasting service relied upon by tens of thousands of broadcasters every month. Our desktop app, built using C++ and QML, is our customers' main tool for interacting with the service and broadcasting live.

Experience with QML is a must. Knowledge of digital audio/internet radio/streaming or web development would be an advantage.

To apply or for more info, please contact jobs@mixlr.com.

SEEKING FREELANCER - Android developer (Remote not possible) LONDON

http://mixlr.com

Mixlr is a platform for social live audio. We build simple and intuitive ways to share and create interaction around live audio streams. We have over two million registered users, including over 30,000 monthly active broadcasters, and we’re growing fast.

We’re looking to meet a great Android developer to join our small, passionate team here in London, and take responsibility for bringing the full Mixlr experience to the Android world. You will have the opportunity to drive the development of our Android app from the first git commit onwards.

The most important single characteristic you will possess is a passion for building great mobile apps, but here are some more attributes which would come in useful:

---

* a passion for implementing fantastic user interfaces

* knowledge of live streaming protocols, especially on mobile

* enthusiasm for music apps and/or audio programming

* experience working with JSON and RESTful APIs and web services

* broad knowledge of different Android devices

* experience with test-driven development

* proficiency of at least one other language apart from Java, especially: C, C++, Ruby or JavaScript

---

You can read more about Mixlr on our Dev Portal[1]. If you would like to discuss this opening more then drop us an email: jobs@mixlr.com.

[1] http://dev.mixlr.com

Android developer - London - Mixlr

http://mixlr.com

Mixlr is a platform for social live audio. We build simple and intuitive ways to share and create interaction around live audio streams. We have over two million registered users, including over 30,000 monthly active broadcasters, and we’re growing fast.

We’re looking to meet a great Android developer to join our small, passionate team here in London, and take responsibility for bringing the full Mixlr experience to the Android world. You will have the opportunity to drive the development of our Android app from the first git commit onwards.

The most important single characteristic you will possess is a passion for building great mobile apps, but here are some more attributes which would come in useful:

---

* a passion for implementing fantastic user interfaces

* knowledge of live streaming protocols, especially on mobile

* enthusiasm for music apps and/or audio programming

* experience working with JSON and RESTful APIs and web services

* broad knowledge of different Android devices

* experience with test-driven development

* proficiency of at least one other language apart from Java, especially: C, C++, Ruby or JavaScript

---

This is a unique opportunity not only to join an early stage startup, but to make your mark building an exciting app from the ground up.

You can visit the Mixlr Dev Portal[1] to read more about working at Mixlr, or email for more information. jobs (at) mixlr.com.

[1] http://dev.mixlr.com

SEEKING FREELANCER - local

Android engineer - London - Mixlr http://dev.mixlr.com

-

Mixlr is a fast-growing platform for social live audio with millions of users across the world.

We would like an experienced engineer help our small, passionate team bring the Mixlr experience to the Android world.

The app will include live audio streaming, chat, discovery and all the key features that mobile users already enjoy in our successful iOS app.

You will have experience of building at least one non-trivial native Android app. The following attributes would also be advantageous:

* dedication to designing and building fantastic user interfaces

* knowledge of live streaming protocols, especially on mobile

* passion for music apps and/or audio programming

* experience working with JSON and RESTful APIs

* broad knowledge of different Android devices

* experience with test-driven development

* proficiency of at least one other language apart from Java, especially: C, C++, Ruby or JavaScript

For more information please see our dev portal: http://dev.mixlr.com

Android engineer - London - Mixlr http://dev.mixlr.com

Mixlr is a fast-growing platform for social live audio with millions of users across the world.

We would like an experienced engineer to join our small, passionate team and take responsibility for bringing the Mixlr experience to the Android world.

The app will include live audio streaming, chat, discovery and all the key features that mobile users already enjoy in our successful iOS app.

You will have experience of building at least one non-trivial native Android app. The following attributes would also be advantageous:

* dedication to designing and building fantastic user interfaces

* knowledge of live streaming protocols, especially on mobile

* passion for music apps and/or audio programming

* experience working with JSON and RESTful APIs

* broad knowledge of different Android devices

* experience with test-driven development

* proficiency of at least one other language apart from Java, especially: C, C++, Ruby or JavaScript

For more information please see our dev portal: http://dev.mixlr.com

London - Mixlr - DevOps engineer

We're looking to meet a forward-thinking DevOps engineer to join us at Mixlr and take responsibility for our comprehensive web and live streaming architecture. Mixlr is a platform for social radio. We make streaming live audio easy for tens of thousands of broadcasters streaming to millions of listeners every month - this means our entire architecture has to be both rock-solid and amazingly scalable. We've already moved mountains to make this happen, and are hugely proud of the system we've built. Now we want to meet the engineer who will take us to the next level of scaling.

We would like to meet a highly competent engineer who has a passion for both music or radio and systems engineering, who will be responsible for maintaining, improving and evolving our entire technical infrastructure. This will include the configuration, deployment and performance-tuning of our live streaming services, web servers, databases, testing services and overall physical and virtual hosting.

Find a longer description of this role here: http://mixlr.com/devops

We're also looking to meet C++, Android and Ruby on Rails developers: http://devblog.mixlr.com/2013/02/01/were-hiring/

Thanks but we are not seeking help from recruiters at this time.

Hey Davy - we're not considering hiring remotely at this time I'm afraid.

London - Mixlr - DevOps engineer

We're looking to meet a forward-thinking DevOps engineer to join us at Mixlr and take responsibility for our comprehensive web and live streaming architecture.

Mixlr is a platform for social radio. We make streaming live audio easy for tens of thousands of broadcasters streaming to millions of listeners every month - this means our entire architecture has to be both rock-solid and amazingly scalable. We've already moved mountains to make this happen, and are hugely proud of the system we've built. Now we want to meet the engineer who will take us to the next level of scaling.

We would like to meet a highly competent engineer who has a passion for both music or radio and systems engineering, who will be responsible for maintaining, improving and evolving our entire technical infrastructure. This will include the configuration, deployment and performance-tuning of our live streaming services, web servers, databases, testing services and overall physical and virtual hosting.

Find a longer description of this role here: http://mixlr.com/devops

We're also looking to meet C++, Android and Ruby on Rails developers: http://devblog.mixlr.com/2013/02/01/were-hiring/

Thanks but we are not seeking help from recruiters at this time.

London: C++, Dev ops/Sysadmin, Android, Ruby on Rails

http://mixlr.com

We're hiring for a number of roles in London - see our blog post for full details and contact info.

http://devblog.mixlr.com/2013/02/01/were-hiring/

London: C++, Dev ops/Sysadmin, Android, Ruby on Rails

http://mixlr.com

Our hiring post: http://devblog.mixlr.com/2013/02/01/were-hiring/

Mixlr is a platform for live audio with nearing 1 million registered users. We've built a series of products based around an extensive live broadcasting infrastructure, all fully maintained and managed in house.

We have a strong sense of product and design, and an interesting and scalable technical architecture.

We've got to where we are as a team of four. Now we're looking to expand and would like to talk to smart and passionate engineers who want to join us.

--- C++ engineer (full-time, London)

Our cross-platform desktop app is written is C++, and is a core part of our service.

We're looking to find somebody who is comfortable with deploying (beautfully written, maintainable) C++ applications to multiple platforms, and has at least a working knowledge of audio or video callbacks and streaming techniques.

We make heavy use of the QT framework, so some familiarity here would be useful, and the standard Unix toolchain features heavily in our workflow (we currently build using MinGW for Windows).

At Mixlr, we debug multithreading problems before breakfast. And because our app is currently a web/native hybrid, being comfortable working with networking and a good knowledge of web development techniques would be an advantage.

--- Dev-ops/Sysadmin (full-time, London).

At Mixlr our product requires an extensive and occasionally challenging backend infrastructure.

We are looking to find an experienced backend engineer with deep knowledge of managing both virtualized and physical environments. A strong knowledge of Amazon Web Services is a must, as that's where our entire stack is deployed right now.

We use Puppet to manage and deploy our servers, Ruby for scripting and run a 100% Linux environment making strong use of the Unix tool chain.

Experience of deploying and monitoring Ruby on Rails applications: we currently extend Nginx with a Lua caching layer, to enable us to use full page-caching for the majority of our website traffic. Being comfortable debugging, maintaining and improving this layer will be essential. Knowledge of MongoDB, Redis and deploying various applications on the Java virtual machine would also be directly relevant.

As with all of our roles, a passion for music and/or audio is a plus!

--- Android developer (full-time, London)

We've already designed and released a successful and well-received mobile application for iOS, and now we are planning to bring the full Mixlr experience to Android devices.

We are looking for an experienced Android developer to join the team on a permanent basis, and design and build Mixlr's Android app - from the first Git commit onwards.

We're looking for somebody to hit the ground running, so were you to apply you should have prior experience in building a non-trivial Android app. You should be confident with advanced Java programming techniques including advanced multithreading techniques.

As with all of our positions, you'll be interacting extensively with our various web services and the wider internet, so being comfortable in the world of networking would be an advantage.

--- Rails developer (full-time, London)

Our website is still the core way in which our users interact with Mixlr, and we have big plans for it going forward.

The ideal candidate would have extensive Ruby on Rails experience and be comfortable working with an extensive Rspec test suite. We make heavy use of the jQuery and Backbone JavaScript frameworks, write our CSS using SCSS, and rely on MongoDB and Redis to store and cache our data.

We would like to meet a smart, passionate Rails developer who is eager to extend their skill set, working on a fast-growing product with thousands of daily users.

If you want to talk more to us, drop me a line: rob@mixlr.com

Great article. Have you read Musicking by Christopher Small? If not, you definitely should.

http://www.amazon.co.uk/Musicking-Meanings-Performing-Listen...

Also, it might be interesting to chat a bit more. Drop me an email - rob at [see profile for domain].

I'm not really sure what point you're trying to make. Are you saying that it's not desirable to reduce the load on your backend web servers?

I'm neither a Lua expert nor an evangelist, but my clear impression is that Lua is much more suited to embedding in a web server than Ruby or Python. On the Lua website it is described as "a powerful, fast, lightweight, embeddable scripting language" - that's not a description I would ascribe to either Ruby or Python. I also know that Lua has a long history of being embedded in games, embedded systems and other servers like Redis. Perhaps somebody more experienced in Lua can help me out here though.

In this case there seems to be good evidence that Lua is the right tool for the job.

One minor point- in your first comment you talk about interpreted Lua code, but this is not accurate because Lua can be compiled down to byte code before being loaded into Nginx.

Finally - "Embedding Python in a web server is quite doable". I would be interested to read a blog post about your experiments in this area ;)

I can imagine a scenario where we wanted a sub-domain which didn't redirect, but also wasn't crawlable. But I agree the example is a little bit contrived ;)

This is a very good talk. Thanks for posting.

Our main goal is to avoid passing requests upstream to Rails, which has massive performance penalties (TCP/IP, probably multiple database hits, web servers written in Ruby).

By keeping everything non-blocking and inside the Nginx event loop, and cutting the upstream out entirely, we are making a massive saving on each request. This definitely outweighs a small performance penalty incurred for using LuaJIT.

I don't know anything about Go but your idea sounds feasible.

As another commenter says, there is a large Nginx community and we have a lot of investment in Nginx already. But for somebody starting from scratch it may be worth considering.

I didn't know about the Weibo connection.

It is a very fast module, and non-blocking, but just as importantly it provides the flexibility to avoid sending requests from Nginx to slow backend servers (Ruby, Python, whatever) at all. In real-life situations, this is the most important bit.

As I said in another thread, we've done some good work to tie this in with our Rails app. We now page cache almost every important request, even for logged in users. This means Rails and our databases are protected from most spikes of traffic. I would like to write a post describing this in more detail, I need to think how to get it across though.

There's no single self-contained solution in the post really, it's more an illustration of a number of useful things that Lua can be used for. I might try to put another post together at some stage though.

For us our main goal is to prevent the majority of requests from even reaching the Rails stack. We've done this by introducing full page caching across the site, for both logged in and logged out users. This means that only a small percentage of requests at peak times need to touch Rails or any database at all - everything is served by Nginx.

This hasn't been without its challenges. The last section of this post might give a clue as to how we've solved the most difficult ones. I will think about a post tackling this whole subject but I need to think about how to get it across, it's not easy.

Please, please don't help to persist the convention of putting the API version number in the URL. There are far better ways of doing it.

http://stackoverflow.com/a/975394/62871

Thanks, it's a good point, I will update the post later.

Yes that works too as I mentioned in the first couple of paragraphs of the post.

However having a beta.mixlr.com domain a) introduces a lot of friction and seriously reduces the ease with which you can test features b) may alter the perception or expectations of a visitor, making testing less valid.

We've got a lot of users and we want to make the roll-out process completely transparent and inclusive.

Hence this solution.

As I explained in the post, that's the intended behaviour.

We want to allow our users to enable beta version for all visitors to their Mixlr page, not just for themselves.

But a cookie approach would be easy too - see my other comment for a simple example.

Cheers. Yeah a cookie approach would be suitable for a lot of uses, including A/B testing. It's easy in Nginx/Lua:

local is_some_cookie_set = nginx.var.cookie_SomeCookie ~= nil;

Then you don't need Redis at all. For us though, we want to separate users by the URL and then a check at an application level variable, so I think this is the right approach still.

Thanks. I didn't know that. I did strip out a lot of the more advanced/ambiguous Nginx config for clarity though.

Perhaps he is a vegetarian. Being homeless doesn't require you to sacrifice your principles.