profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/hubertlepicki/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Hubert Łępicki hubertlepicki AmberBit Ruby on Rails & Elixir web development Białystok, Poland https://www.amberbit.com

hubertlepicki/cheap-themes 33

Cheap Themes adds dead easy theming support for Rails views and also a way of customizing controller actions on per-theme basis.

hubertlepicki/capybara-tasks-template 11

Template repository illustrating how to use Capybara automate performing tasks online

hubertlepicki/cap-recipes 3

Battle-tested capistrano recipes for passenger, apache, and more

hubertlepicki/amberbit-config 2

Simple configuration framework for Rails applications based on YAML files

hubertlepicki/Bialystook 2

Zamienia "Lubię to" na "Dla mnie się to podoba" a "Nie lubię" na "Badziewie". Dla użytkowników FIrefoxa i Google Chrome.

hubertlepicki/active_reload 1

Reload Rails code in development mode only when change is deteced

hubertlepicki/anemone 1

Anemone web-spider framework

hubertlepicki/awesome-elixir 1

A curated list of amazingly awesome Elixir and Erlang libraries, resources and shiny things.

hubertlepicki/aws 1

AWS library

push eventhubertlepicki/surface

Hubert Łępicki

commit sha b7f0e5426c52c3592aaee5ca759e8e7b95d6d984

[#481] Disable build timestamp, replace header This change removes the build timestamp from headers of the generated files. This change also improves the tests by generating the hook files in the tests themselves, making sure their content changes and not just rely on the timestamps / build times.

view details

push time in a day

issue commentsurface-ui/surface

Can we disable build time timestamp?

@msaraiva right. I removed the path to the source file completely, the PR is ready.

hubertlepicki

comment created time in a day

issue commentsurface-ui/surface

Can we disable build time timestamp?

Done & ready for review.

hubertlepicki

comment created time in a day

push eventhubertlepicki/surface

Hubert Łępicki

commit sha 8168ce1c74e8aa08eac5dec8a25885c8fe946e85

[#481] Disable build timestamp, replace header This change removes the build timestamp from headers of the generated files, and replaces it with a helpful message pointing to the original source files that should be modified instead of the current file. This change also improves the tests by generating the hook files in the tests themselves, making sure their content changes and not just rely on the timestamps / build times.

view details

push time in a day

issue commentsurface-ui/surface

Can we disable build time timestamp?

I found one issue with this where I added the path to the header it exposes full filesystem path. I'll have to update it so it's only a relative path otherwise we may be exposing something build-time that we don't want to be exposed like filesystem structure on the build environment. So, hold off merging this. I need to update the PR. but you can give me feedback on the approach!

hubertlepicki

comment created time in a day

issue commentsurface-ui/surface

Can we disable build time timestamp?

@msaraiva I actually had some thoughts that maybe are not inline with yours but I went ahead and implemented as it was quick and probably shows better then intent than discussing.

In short, the PR above updates the header, but also generates the hook files in the test set up itself. My thinking is that I don't like adding code, not even the dependency injection, just for the sake of testing, and instead prefer the higher level test that does the set up & cleanup. So, in the PR above we're now generating the hook files in the setup block itself.

At the same time, I figured the message in header files could be a bit more helpful and point the user to the source files, which I added.

Please let me know what you think of the above, obv, this is just a proposal so if you don't like it no hurt feelings.

hubertlepicki

comment created time in a day

PR opened surface-ui/surface

[#481] Disable build timestamp, replace header

This change removes the build timestamp from headers of the generated files, and replaces it with a helpful message pointing to the original source files that should be modified instead of the current file.

This change also improves the tests by generating the hook files in the tests themselves, making sure their content changes and not just rely on the timestamps / build times.

Closes #481

+54 -35

0 comment

5 changed files

pr created time in a day

fork hubertlepicki/surface

A server-side rendering component library for Phoenix

https://surface-ui.org

fork in a day

push eventhubertlepicki/spike

Hubert Łępicki

commit sha 8f47828f8ad7fd9e60d8a2df12b3e68c5ac37a6a

Small refactoring, mostly for the sake of better stacktraces

view details

push time in 10 days

push eventhubertlepicki/spike

Hubert Łępicki

commit sha 7f120a02d27a84e28eee13cb7e577ecaa6bd8504

Fix bug where updating one field twice failed

view details

push time in 11 days

create barnchhubertlepicki/spike

branch : main

created branch time in 11 days

created repositoryhubertlepicki/spike

Spike helps you build stateul forms / UIs with Phoenix LiveView (and/or Surface UI)

created time in 11 days

issue commentsurface-ui/surface

Can we disable build time timestamp?

The problem is that the modification date's precision is provided in seconds which makes it unsuitable for some of the tests we have. However, instead of a configuration, we could print the build time only when in test env. WDYT?

Yes, we can do that. I had a glance at the tests and it looks like the build time is used here, mostly for this test to see that the file changed when you rebuild it, which actually shows the issue I'm having precisely: source files didn't change and yet the resulting compiled file did. https://github.com/surface-ui/surface/blob/c5c0b1b26228d1f96a83dd14694071030858eab7/test/mix/tasks/compile/surface_test.exs#L108

How about I refactor the test in a way that it actually modifies the source files, to check if recompilation happens and the resulting compiled file has the modifications made instead of the current one that relies on adding build time line? In such case we wouldn't have to add build time at all, not even in tests, and we'd have slightly better, real-life testing scenario.

hubertlepicki

comment created time in 24 days

issue openedsurface-ui/surface

Can we disable build time timestamp?

I would like to add a config option to Surface that would disable adding "Build time: " line. The code in question is here:

https://github.com/surface-ui/surface/blob/6164224a7b156dd41327db7142af7eae182e86bb/lib/mix/tasks/compile/surface.ex#L176

The reasoning is that it annoys me when switching branches and is being added to commits by developers by mistake, even if nothing changes, resulting in merge conflicts that have to be resolved.

I can provide a PR.

That is if you want to keep this. I am not sure this timestamp is needed at all - the file on the filesystem can be also queried for modification date, so maybe we don't need it at all and can just rely on that? If that' spreferred I'd remove the line completely.

created time in a month

create barnchhubertlepicki/test-codespaces

branch : main

created branch time in a month

created repositoryhubertlepicki/test-codespaces

created time in a month

issue commentsurface-ui/surface

Tag 0.5.2 hasn't been pushed to GitHub, resulting in HexDocs links being broken

This works perfectly. Quoting Jose here:

:blue_heart: :heart: :green_heart: :yellow_heart: :black_heart: :orange_heart:

hubertlepicki

comment created time in a month

issue commentsurface-ui/surface

Tag 0.5.2 hasn't been pushed to GitHub, resulting in HexDocs links being broken

Yep, that was super confusing to me as well and I think I opened a separate issue but yes it totally makes sense to update this - or push a v0.5.3 with these fixes, but I'll take either.

On Fri, Aug 6, 2021 at 2:14 PM Marlus Saraiva ***@***.***> wrote:

Done!

Thanks @hubertlepicki https://github.com/hubertlepicki for pointing that out.

I'm also updating some of the docs for v0.5.2 to replace {{ ... }} with { ... }. We did that on master but it should have be done on the v0.5 branch too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/surface-ui/surface/issues/474#issuecomment-894218610, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAID6V543LAZE2ZQTLFWV3T3PGZXANCNFSM5BVVKZNA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

-- Hubert Łępicki phone: +48 694 161 264 email/Google+: @***. Skype: hubert.lepicki

AmberBit Sp. z o. o. ul. Hetmańska 42 lok. 205 15-727 Białystok

AmberBit Sp. z o. o. jest wpisana do Rejestru Przedsiębiorców Krajowego Rejestru Sądowego prowadzonego przez Sąd Rejonowy w Białymstoku, XII Wydział Gospodarczy Krajowego Rejestru Sądowego. Kapitał zakładowy 20 000,00 zł opłacony w całości. EU VAT: PL5423228204, NIP: 5423228204, KRS: 0000439100, REGON: 200741641

hubertlepicki

comment created time in a month

issue openedsurface-ui/surface

Tag 0.5.2 hasn't been pushed to GitHub, resulting in HexDocs links being broken

The HexDocs pages have links that return 404, because of the tag that's not in GitHub.

Someone with admin rights to the repo could fix it by pushishing the v0.5.2 tag... please :)

For example, this page: https://hexdocs.pm/surface/Surface.LiveView.html links to this page that returns 404: https://github.com/surface-ui/surface/blob/v0.5.2/lib/surface/live_view.ex#L1

created time in a month

push eventhubertlepicki/vim-elixir

Hubert Łępicki

commit sha e70f614f525e8fee8b4676e006182770fcf07d86

Update Surface UI support for version >= 0.5.0

view details

push time in a month

create barnchhubertlepicki/vim-elixir

branch : add_surface_sigil_f_support

created branch time in a month

issue commentsurface-ui/surface

Docs specify wrong / outdated (?) syntax for things like options

Indeed it was, thanks @Malian !

hubertlepicki

comment created time in a month

issue commentpeburrows/goth

Using Goth on GAE with no extra configuration - Config.get(:client_email) errors

right, ok that's what I was thinking too about future of Goth and I was wondering if that even makes sense to add that functionality to the legacy modules if the intended usage is to not have them at some point. I think this makes sense @wojtekmach , but would be good for @peburrows to confirm

hubertlepicki

comment created time in 2 months

issue openedsurface-ui/surface

Docs specify wrong / outdated (?) syntax for things like options

I think the docs are using wrong syntax for component parameters. For example, the documentation for TextInput proposes the following syntax:

<TextInput form="user" field="name" opts={{ autofocus: "autofocus" }} />

This is on the following link: https://hexdocs.pm/surface/Surface.Components.Form.TextInput.html#content

I have found in the tests that the correct form is, however:

<TextInput form="user" field="name" opts={ autofocus: "autofocus" } />

I don't know the history here but I suspect double mustache is historically valid (?) but new syntax uses single mustache instead?

I am using surface v0.5.2.

created time in 2 months

push eventamberbit/waffle_gcs

Hubert Łępicki

commit sha d419efa7ba44b132622e42fe055e210e488e75de

Support GAE / Google Default Application Credentials

view details

push time in 2 months

push eventamberbit/waffle_gcs

Hubert Łępicki

commit sha fa6d4ed91167b65d2deec961567abe836ec76972

Support GAE / Google Default Application Credentials

view details

push time in 2 months

push eventamberbit/waffle_gcs

Hubert Łępicki

commit sha fed81911976dde89b3299e15ed7b94909833cb2d

Support GAE / Google Default Application Credentials

view details

push time in 2 months

issue commentpeburrows/goth

Using Goth on GAE with no extra configuration - Config.get(:client_email) errors

@wojtekmach I'd like to make a proper fix to this at some point and was just wondering if you think client_email should be resolved by Goth the same way the project_id currently is, i.e. using instance metadata when on GAE / GCP, and thus the functionality to do so should be added to Goth, or should I continue doing that outside of Goth?

hubertlepicki

comment created time in 2 months